From owner-freebsd-arch@FreeBSD.ORG Mon Jul 24 17:32:15 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D469B16A4DF; Mon, 24 Jul 2006 17:32:15 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 228B343D46; Mon, 24 Jul 2006 17:32:14 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060724173209m910087fine>; Mon, 24 Jul 2006 17:32:09 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k6OHW6jG093142; Mon, 24 Jul 2006 12:32:06 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k6OHW64Q093141; Mon, 24 Jul 2006 12:32:06 -0500 (CDT) (envelope-from brooks) Date: Mon, 24 Jul 2006 12:32:05 -0500 From: Brooks Davis To: Robert Watson Message-ID: <20060724173205.GD91329@lor.one-eyed-alien.net> References: <20060723171734.K35186@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C1iGAkRnbeBonpVg" Content-Disposition: inline In-Reply-To: <20060723171734.K35186@fledge.watson.org> User-Agent: Mutt/1.5.11 Cc: arch@freebsd.org Subject: Re: sosend/soreceive consistency improvements X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 17:32:16 -0000 --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--