From owner-freebsd-net@FreeBSD.ORG Wed May 21 15:40:22 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 687B837B401 for ; Wed, 21 May 2003 15:40:22 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id A793C43F75 for ; Wed, 21 May 2003 15:40:21 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc02) with ESMTP id <20030521224020002002lafme>; Wed, 21 May 2003 22:40:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA75572; Wed, 21 May 2003 15:40:18 -0700 (PDT) Date: Wed, 21 May 2003 15:40:17 -0700 (PDT) From: Julian Elischer To: Vincent Jardin In-Reply-To: <200305212341.11282.vjardin@wanadoo.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-net@freebsd.org Subject: Re: netgraph: why does ng_ether bother enqueuing packets? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 22:40:22 -0000 On Wed, 21 May 2003, Vincent Jardin wrote: > Le Mercredi 21 Mai 2003 23:03, Dave Dolson a =E9crit : > > For reasons of performance, I tried the following modification to > > ng_ether.c in FreeBSD 4.7, and it seemed to work fine. > > The change is to call ng_send_data() vs. ng_queue_data(). The change is ok as long as you know that you are at splnet. in 5.x the change is probably not needed. > > > > We are running in polling mode, so ng_ether_input is called @ netisr > > anyhow. (Always ?) >=20 > What's about the ng_ether's node that are created on the ethernet interfa= ces=20 > that do not support polling ? >=20 > > > > static void > > ng_ether_input2(node_p node, struct mbuf **mp, struct ether_header *e= h) > > { > > const priv_p priv =3D node->private; > > meta_p meta =3D NULL; > > int error; > > > > /* Glue Ethernet header back on */ > > if ((error =3D ng_ether_glueback_header(mp, eh)) !=3D 0) > > return; > > > > /* Send out lower/orphan hook */ > > + #ifdef DEVICE_POLLING > > + /* send directly, since we're already @ splnet */ > > + (void)ng_send_data(priv->lower, *mp, meta); > > + #else > > (void)ng_queue_data(priv->lower, *mp, meta); > > + #endif > > *mp =3D NULL; > > } > > > > Does anyone know why this might be bad? > > Any reason why this couldn't be done in interrupt (non-polling) mode al= so? > > Theoretically the queueing code should work whether or not you are doing polling. it just may increase the latency.. I don't know if there is a way that we can tell if we are at splnet, but if there is then a run-=3Dtime decision would be best, instead of a compile time decision. =20