Date: Wed, 20 May 2009 21:57:23 +0200 From: Andre Oppermann <andre@freebsd.org> To: rmacklem@uoguelph.ca, dfr@rabson.org, rwatson@FreeBSD.org Cc: freebsd-current@freebsd.org Subject: Socket related code duplication in NFS Message-ID: <4A1460A3.2010202@freebsd.org>
next in thread | raw e-mail | index | archive | help
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:
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?4A1460A3.2010202>