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

>
> 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()
>