Date: Thu, 22 Jul 1999 17:30:24 -0700 From: Mike Smith <mike@smith.net.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, jkh@FreeBSD.org Subject: Re: cvs commit: src/release/sysinstall tcpip.c Message-ID: <199907230030.RAA03011@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 23 Jul 1999 01:23:05 %2B0200." <31978.932685785@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> That is really a deficiency of our ethernet layer (on my todo-list
> way down there...) Each ethernet driver shouldn't have to know
> as much as it does about the input path for packets, or for that
> matter if bpf is there or not.
The basic problem here is that bpf et. al. want the whole datagram,
while ether_input wants it broken up into the header and body.
The ether_output side is relatively straightforward (as long as you
don't mind BPF getting the datagram as soon as it's enqueued rather
than when it's moved off the interface queue onto the adapter's work
queue).
There are two approaches we can take here; either we change ether_input
to take the raw packet (alters the driver API) or we shim bpf to
reconstruct the packet.
In most cases though, a driver does this:
(m = incoming mbuf)
bpf_mtap(ifp, m);
eh = mtod(m, struct ether_header *);
m_adj(m, sizeof(struct ether_header));
ether_input(ifp, eh, m);
which means that in the latter case we can optimise the BPF input
process thus:
if ((eh + 1) == mtod(m, struct ether_header *)) {
m_adj(m, -sizeof(struct ether_header));
bpf_mtap(ifp, m);
m_adj(m, sizeof(struct ether_header));
} else {
... reconstruct the packet ...
}
This can then be stuck right at the top of ether_input, followed by the
traditional per-driver tests for promiscuous/multicast/broadcast mode.
That'd completely remove the need for any conditionalisation on BPF in
device drivers.
The next step would be to use a callout list in ether_input, allowing
multiple consumers to register/deregister their interest in incoming
datagrams on a per-interface basis. In reality, the cost of an
indirect jump vs. the cost of ether_input is infestimal, but a callout
list is cheaper and more flexible anyway.
Comments?
(Yes, I can commit real time to doing this work.)
--
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ msmith@freebsd.org
\\ -- Joseph Merrick \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907230030.RAA03011>