netgraph: why does ng_ether bother enqueuing packets?

Julian Elischer julian at elischer.org
Wed May 21 15:40:22 PDT 2003



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




More information about the freebsd-net mailing list