Date: Wed, 20 May 2009 21:06:05 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: rmacklem@uoguelph.ca, freebsd-current@freebsd.org Subject: Re: Socket related code duplication in NFS Message-ID: <alpine.BSF.2.00.0905202102100.25537@fledge.watson.org> In-Reply-To: <4A1460A3.2010202@freebsd.org> References: <4A1460A3.2010202@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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()
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0905202102100.25537>