Subject: Re: CVS commit: syssrc/sys/net
To: None <>
From: Atsushi Onoe <>
List: tech-net
Date: 09/30/2002 21:24:01
> Why do we need bpf_tap, bpf_mtap and bpf_mtap2 ?

> That said, your proposal for bpf_mtap2() was:
> void bpf_mtap2(caddr_t bpf, caddr_t hdr, int hdrlen, struct mbuf *m);

bpf_tap and bpf_mtap can be integrated or even defined by macro to use

> The first problems is that the hdr part needs to be in an mbuf,
> sooner or later and putting it directly in with the code in
> if_ieee1394subr.c saves having to copy that again.

Moving the code in if_ieee1394subr.c to bpf_mtap2 doesn't introduce
more or less overhead at all.

> I think you're missing the point I raised.

OK, but it is a different issue from the mbuf initializer.

> IDS software will use BPF to get packets from the network.  Having
> spoken to at least one vendor about doing that, their main gripe
> was how slow BPF was.  That's the in-kernel BPF being slow.
> Hence, I'm interested in knowing what we can do in a general manner
> to make BPF faster, as well as better and less buggy.  I made a bunch
> of changes to bpf_filter() after hearing this that made the kernel
> code not use m_xword() and friends all the time (this is now in
> libpcap.)
> Replacing the current use of a mbuf on the stack with MGET will not
> make it any quicker.
> Actually, in these cases, it makes no difference :-(  libpcap generates
> code that expects there to be a 4 byte DLT_NULL header, and this forces
> all bpf accesses to use m_x*() because 'buflen == 0' from bpf_mtap. :(
> That said, a bpf_mtap2() will not solve *that* problem either :-/

Yes, but it isn't worse in performance then expose fake mbuf and
hide fake mbuf into bpf is a good point then.

Perhaps, add extra space for link header at using mbuf in drivers
if possible, and use of M_PREPEND() could be better for performance.
Unlike old BSD mbuf functions, our M_PREPEND() can be used also for
mbuf clusters.
Obviously, it cannot be applied for if_loop, but I'm not sure IDS want
to see loopback interface.

How about proposing such manner in use of bpf_mtap if you really think
the performance for bpf is the issue?

Atsushi Onoe