Re: sosend/soreceive consistency improvements

On Sun, Jul 23, 2006 at 07:57:56PM +0100, Robert Watson wrote:

As part of cleanups, locking, and optimization work, I've been looking at
the socket send and receive paths.

In the past, work was done do allow the uio/mbuf chain send and receive
paths (sosend, soreceive) to be pluggable for a protocol, so that the
protocol could provide substitute implementations. This is not, generally,
currently used, although I recently changed UDP to use an optimized
datagram send routine. This pluggability is made possible by virtue of each
protocol providing its own pru_sosend() and pru_soreceive() methods in the
protocol switch.

There's another side to the pluggability, however -- the socket consumers
in the kernel, of which there are quite a few -- obviously the socket
system calls, but also netgraph, distributed file systems, etc. Some of
these consumers have been modified to call
so->so_proto->pr_usrreqs->pru_soreceive and ...->pru_sosend, but it turns
out many haven't. New references to sosend() and soreceive() periodically
get encoded into consumers -- presumably because they are easy to spell,
and in fact are generally functionally identical. But not always! It
turns out that the NFS code isn't using the optimized UDP send path via
sosend_dgram(), because it's calling sosend() directly.

Rather than continue in this "in between state", in which the uio/mbuf
chain sosend and soreceive are reached via the protocol switch in each
occurrence, I propose a change: sosend() and soreceive() will now be the
formal APIs for sending and receiveing on sockets within the kernel, as is
the case with many other so*() functions, and they will perform the
protocol switch dereference. The existing functions are renamed to
sosend_generic() and soreceive_generic(), and in most cases are never
referenced by protocols since our protocol domain registration already uses
sosend() and soreceive() as the defaults today. The new code strikes me as
quite a bit more readable, and likely easier for socket consumers to use.

Any thoughts and/or objections?

Makes sense to me. Is there an measurable performance impact? I
wouldn't really expect much if any, but it's probably worth a check.
The function is a fairly obvious target for inlining if there is any.

-- Brooks

Attachment: pgpGxVts3O08u.pgp
Description: PGP signature

Relevant Pages

  • HEADS UP: network stack and socket hackery over the next few weeks
    ... Over the next few weeks, I'll be doing a fairly serious workworking of the socket and protocol reference models, in order to clean up a number of long-standing race conditions and provide infrastructure for significant locking optimizations for several protocols (including TCP). ...
    (freebsd-current)
  • Re: socket arguments
    ... a protocol argument of zero means unspecified. ... socket type, protocol) parameters. ... ProviderFlags: MatchesProtoZero ...
    (microsoft.public.win32.programmer.networks)
  • Re: CAsyncSocket on vista
    ... The error you are getting is WSAEAFNOSUPPORT - Address Family Not ... Perhaps when you are setting up your socket you are not initialising all ... WSAEAFNOSUPPORT Address family not supported by protocol family. ... Conversation: CAsyncSocket on vista ...
    (microsoft.public.vc.mfc)
  • Re: Multithread safety
    ... If your protocol is TCP, then yes, you need to reassemble the read results. ... Multiple threads writing to the same socket - now that is ... Washington WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Historical question
    ... Why was it decided that NICs don't have ... >Another use would be for sniffing traffic by doing cat on the socket. ... for 'protocol' identifier. ... Also, by standard implementation, filesystem resources are 'shared access' ...
    (comp.unix.bsd.freebsd.misc)