While working on an optimized soreceive_stream() function [1] and checking the code how it is used I've come across quite a bit of code duplication in the various NFS directories. Socket (read) operations are handled multiple times in a very similar manner in these places: sys/rpc sys/nfsclient sys/nfsserver Also how the soreceive call is used is interesting. It certainly can be made more efficient overall. My questions/observations/suggestions are as follows: a) Can the socket handling code be unified in one place for all NFS? b) The socket upcall mechanism is done per packet and can get expensive for fast networks. It also has some additional unlock/lock overhead plus that is delays protocol processing (even more so with netisr direct dispatch where the code is run from an ithread). c) Can NFS be made to use a select() mechanism where it gets notified when new data arrives? Just like in userspace. d) If not, it may be beneficial to have a taskqueue handle the upcall and have the soappend call return immediately to complete processing of the the protocol. e) The socket buffer is most efficient when it can aggregate a number of packets together before they are processed. Can the NFS code set a low water mark on the socket to get called only after a few packets have arrived instead of each one? (In the select and taskqueue model.) f) I've been thinking of an modular socket filter approach (much like the accept filter) scanning for upper layer specific markers or boundaries and then signalling data availability. -- Andre [1] Perforce: //depot/user/andre/soreceive_stream/kern/uipc_socket.c::soreceive_stream()Received on Wed May 20 2009 - 18:24:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:48 UTC