[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bpf jit
> 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
Main Index |
Thread Index |