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

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Limits on jumbo mbuf cluster allocation
    ... socket buffers should be no more than twice that -- i.e., ... I did so for the client some time ago.;-) ... We really have to look into that NFS socket interaction to get this ...
    (freebsd-net)
  • Socket related code duplication in NFS
    ... Socket operations are handled multiple times in a very similar manner ... Can the socket handling code be unified in one place for all NFS? ... packets together before they are processed. ... f) I've been thinking of an modular socket filter approach (much like the ...
    (freebsd-current)
  • [fw-wiz] NFS and Cisco
    ... I have been seeing NFS problem on my network lately, after nfs worked well for years. ... the nfs server and client I see client sending packets to the server, ... but the reply packets never make it to the client. ...
    (Firewall-Wizards)
  • Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL
    ... A NULL pointer dereference here suggests that a second thread has closed the socket while it was in use by the first thread reconnecting it --possibly a race condition in the NFS client code, given that the connection wasn't actually connected yet? ... Try "info threads" and see if that shows up in an obvious manner -- perhaps the shutdown thread is in the VFS tear-down from boot? ...
    (freebsd-net)
  • Re: How necessary is SSH_AUTH_SOCK?
    ... How is having the socket file on an NFS server a problem? ... an NFS environment, as it means anyone can read any files which are ... With some pain it can be more secure (i.e. access controls on all your ...
    (SSH)