Socket related code duplication in NFS
Robert Watson
rwatson at FreeBSD.org
Wed May 20 20:06:06 UTC 2009
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()
>
More information about the freebsd-current
mailing list