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