Subject: Re: CVS commit: syssrc/sys/net
To: None <email@example.com>
From: Atsushi Onoe <firstname.lastname@example.org>
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
> 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
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?