Socket related code duplication in NFS

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