Date: Mon, 24 Jul 2006 12:32:05 -0500 From: Brooks Davis <brooks@one-eyed-alien.net> To: Robert Watson <rwatson@freebsd.org> Cc: arch@freebsd.org Subject: Re: sosend/soreceive consistency improvements Message-ID: <20060724173205.GD91329@lor.one-eyed-alien.net> In-Reply-To: <20060723171734.K35186@fledge.watson.org> References: <20060723171734.K35186@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--C1iGAkRnbeBonpVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 23, 2006 at 07:57:56PM +0100, Robert Watson wrote: >=20 > As part of cleanups, locking, and optimization work, I've been looking at= =20 > the socket send and receive paths. >=20 > In the past, work was done do allow the uio/mbuf chain send and receive= =20 > paths (sosend, soreceive) to be pluggable for a protocol, so that the=20 > protocol could provide substitute implementations. This is not, generall= y,=20 > currently used, although I recently changed UDP to use an optimized=20 > datagram send routine. This pluggability is made possible by virtue of ea= ch=20 > protocol providing its own pru_sosend() and pru_soreceive() methods in th= e=20 > protocol switch. >=20 > There's another side to the pluggability, however -- the socket consumers= =20 > in the kernel, of which there are quite a few -- obviously the socket=20 > system calls, but also netgraph, distributed file systems, etc. Some of= =20 > these consumers have been modified to call=20 > so->so_proto->pr_usrreqs->pru_soreceive and ...->pru_sosend, but it turns= =20 > out many haven't. New references to sosend() and soreceive() periodicall= y=20 > get encoded into consumers -- presumably because they are easy to spell,= =20 > and in fact are generally functionally identical. But not always! It=20 > turns out that the NFS code isn't using the optimized UDP send path via= =20 > sosend_dgram(), because it's calling sosend() directly. >=20 > Rather than continue in this "in between state", in which the uio/mbuf=20 > chain sosend and soreceive are reached via the protocol switch in each=20 > occurrence, I propose a change: sosend() and soreceive() will now be the= =20 > formal APIs for sending and receiveing on sockets within the kernel, as i= s=20 > the case with many other so*() functions, and they will perform the=20 > protocol switch dereference. The existing functions are renamed to=20 > sosend_generic() and soreceive_generic(), and in most cases are never=20 > referenced by protocols since our protocol domain registration already us= es=20 > sosend() and soreceive() as the defaults today. The new code strikes me = as=20 > quite a bit more readable, and likely easier for socket consumers to use. >=20 > 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 --C1iGAkRnbeBonpVg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFExQQVXY6L6fI4GtQRAjGAAKCjDjqRR/cWKa4nQGd4afgyLUlIKgCfUp1k SyoZWWIxUgs4/Afn+mVlllg= =lV/a -----END PGP SIGNATURE----- --C1iGAkRnbeBonpVg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060724173205.GD91329>