Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 May 2003 15:40:17 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Vincent Jardin <vjardin@wanadoo.fr>
Cc:        freebsd-net@freebsd.org
Subject:   Re: netgraph: why does ng_ether bother enqueuing packets?
Message-ID:  <Pine.BSF.4.21.0305211536150.22764-100000@InterJet.elischer.org>
In-Reply-To: <200305212341.11282.vjardin@wanadoo.fr>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0305211536150.22764-100000>