Re: bpf jit

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Alexander Nasonov <alnsn%yandex.ru@localhost> wrote:
> > It is true that mbuf chains are not supported, but the size of the
> > packet does not really matter here.  Most of the filtering operations
> > are done only on layer 3 and/or 4 headers, i.e. it is a common case.
> > IP and other layers (AFAIK in a vast majority of the cases) it is
> > ensured that these headers will be in a single (and the first) mbuf.
> > So, if one performs m_copyback() (which would nearly always be a NOP),
> > to guarantee one contiguous mbuf, it is perfectly safe to use.  It also
> > meets NPF/n-code needs for now.
> 
> I probably miss something here. Device drivers don't know whether your
> bpf program access only L3 headers or any byte in a large packet.
> Therefore, you can't just give the first mbuf to bpf, you have to pass
> the whole mbuf chain to bpf.

BPF program producers, such as libpcap or say NPF, can know and can pass
that knowledge.  If inspecting outside the L3/L4 headers, you just fallback
to non-JIT code.  Also, with m_copyback(), m_pullup() or other routine from
this family you guarantee (i.e. it copies, if needed) that these headers
will be in the first mbuf of the chain, but as already pointed out - other
layers in the stack, e.g. IP, do that already so it is normally a NOP.

> Size of a packet doesn't affect bpf performance directly but the
> interpreter does. If large packets are common in your workload (nfs,
> ftp, etc) then it's often quite demanding environment and it's probably
> more important to optimize any overhead compared to a case where all
> packets are small.

We talk about L3/L4 headers as a common case (for n-code, which is my
interest, it would be the only case for now).  Unless you talk about
something like application layer filtering, I do not see how the size
matters.  However, we already agree that handling of mbuf chains is an
important feature to have.

-- 
Mindaugas