Re: Socket related code duplication in NFS

On Wed, 20 May 2009, Andre Oppermann wrote:

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:

My recommendation would be to do this analysis against the new NFS client and server found in sys/{kgssapi,nlm,fs/{nfs,nfsclient,nfsserver}}, which is the NFSv234 implementation. Note in particular that in the new world order there's a centralize RPC implementation.

The code you're looking at is a blend of the old NFSv23 client/server (nfsclient/nfsserver) and the old NFSv4 client (rpc/nfs4client), all if which are on a gradual de-orbit burn.

Robert N M Watson
Computer Laboratory
University of Cambridge


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.


[1] Perforce: //depot/user/andre/soreceive_stream/kern/uipc_socket.c::soreceive_stream()

freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"