Re: bpf jit

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

Mouse wrote:
> It seems to me a better first question is, should either of them be
> used?  They sound to me like solutions in search of problems.

If you use bpf only to run tcpdump once in a while then you probably
don't need jit but if you run intrusion detection system or use many
bpf rules for monitoring, then you would probably benefit from jit.

> Are there measurements supporting the idea that the BPF pcode engine is
> a performance bottleneck?

I didn't do any measurements myself of the whole system because I don't
have access to any test framework but jitted code is 3-5 times faster in
my benchmark. In absolute values it's IIRC 30ns per packet on my amd64
and 150-200ns on my Tegra-250 arm. This is for a simple rule, difference
is greater for more complicated rules.

> Particularly since it seems to me that the CPUs it supports are the ones
> least in need of a performance boost?
Mine supports several cpu types. Or do they all fall into "least in need
of a performance boost"?

> Unless this proposal involves dropping support for BPF on all other
> arches, which I also haven't seen mentioned, the maintenance load of
> the pcode engine will not go away, so I'm having trouble seeing a BPF
> jitter as a good thing.

bpf pcode will not go away. bpfjit will be optional.

> I'm also concerned about it from a slightly different perspective.
> From the sound of it, this is still a research project, albeit one
> that's beginning to see a little use outside the lab.  Compilers are,
> in general, full of subtle corner cases; jitters, even more so.

Why do you think that jitters are more full of subtle corner cases?

Perhaps I should clarify a bit. sljit is not really jit which you
typically find in modern interpreted languages, sljit is much simpler.
It's a code generator with an ability to change jumps and constants on
the fly. But I don't use these facilities in bpfjit. I use sljit as a
pure code generator.

> And BPF is highly privileged, highly exposed, and security critical; it
> seems to me that all the indications are against putting a jitter
> there.  It's raising way too many of my red flags for me to be
> comfortable with it.
> 
> In NetBSD proper, that is.  It's a lovely thing to experiment with; I
> just don't think it belongs in the main tree.

Yes, I'm aware it's highly exposed code but I'm not pushing it to
NetBSD-6. We have time to test and improve before the next branching
of head.

Alex