Re: bpf jit

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> [...] bpf_jit [...] bpfjit [based on] sljit [...]

> I'd like to conclude my lengthy post with a question.  Which of these
> two implementations should be used by NetBSD?

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.  Are
there measurements supporting the idea that the BPF pcode engine is a
performance bottleneck?  I don't recall seeing any (though of course I
could have missed something)...and, if not, why would NetBSD want to
replace a simple MI engine by a complex MD engine, especially in
something as exposed and security-critical as BPF?  Particularly since
it seems to me that the CPUs it supports are the ones 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.

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

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B