Re: bpf jit

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

Mindaugas Rasiukevicius wrote:
> No, it is not broken if used in a certain way (which is actually the
> common case) - see below.

I still believe it's broken because you pass a pointer to mbuf chain and
non-zero pktlen. I fixed non-jit path and I pass buflen (which is zero
for mbuf chains) instead of pktlen but I didn't change jit path because
it wouldn't fix the code anyway because jit doesn't support mbuf chains.
Perhaps I should have changed jit path as well because it's safe to
reject a packet of zero length than to read mbuf object as it was a raw
packet data.

Try running bpfiltermchain test with jit enabled. It's rump test, you
will need to recompile rump libs. (disclaimer: I didn't do it myself).

> Do you have any numbers?  With the current BPF JIT, it is more than 2x
> performance increase:
> 
> http://www.netbsd.org/~rmind/bpf_jit_times.txt

2x is not very impressive but you benchmarked testcases. It'd be better
to benchmark a common filter. I use the second example from bpf(4):
"accept only IP packets between host 128.3.112.15 and 128.3.112.35"
and I get 3-5x speedup.

> 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.

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.

> BPF JIT from FreeBSD is something what is here, works and is more tested.
> Seems (or seemed?) smaller and simpler to work with as well, since SLJIT
> was not ready to be used as an in-kernel JIT at all.  As I understand,
> you have addressed this by now.

Yes, making it work in the kernel was quite easy.

> I guess the problem with SLJIT is that nobody else here is familiar with it
> besides yourself, therefore it is difficult to decide on its suitability.

How many people are familiar with x86 binary instruction encoding? How
many people are familiar with encodings of all architectures supported
by sljit?

I encourage you to take a look at my code and at sljit. I believe it's
easier to learn sljit than learning instruction formats for multiple
architectures.

> Lack of documentation, as you already pointed out, contributes to this as
> well.  There are various other questions unanswered, e.g. would we diverge
> SLJIT code in favour of better integration into NetBSD?  Would the changes
> be committed to upstream or we would maintain SLJIT ourselves or perhaps
> would even take over the maintenance?

The author of sljit is in the discussion. Perhaps he can answer these
questions?

Alex