Re: BPF memstore and bpf_validate_ext()

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

Alexander Nasonov <alnsn%yandex.ru@localhost> wrote:
> All your recent changes to adapt bpfjit for npf show that you're hitting
> sljit limitation all the time. Your expectations of sljit are probably
> too high.

We are discussing the external memory store which is useful regardless
whether BPF program is JIT-compiled or not.  It is a win in both cases.

Also, it was you who proposed sljit.  It can optimise *most* practical
cases (80-20 rule) and I am happy with that.  I do not understand why
are you concerned about those rare/unusual cases.  Do you have some
particular application in mind?  Something else than in our tree?

> <...>
> 
> When I later was implementing copfunc calls in bpfjit, I din't know
> how you gonna use external memory and I felt that it wasn't necessary
> (and I still do), so I changed your structs.

We can pass the memstore pointer as a separate argument (it would be
three arguments, fine for sljit), but what's the point..

> <...>
> 
> By not making memory external I avoided doing a lot of changes in
> bpfjit to adapt to a new execution model.
> 
> Now you want to have *both* external memory and copfuncs for a faster
> execution of your code without considering other uses of bpfjit.
> 
> To be honest, I'm not very intersted in implementing external memory
> in bpfjit. Quite the opposite, after all these discussions I want
> to improve my index check optimization and make filters like 'host xxx'
> run a bit faster. Needless to say that this optimization is the most
> effective if bpf memory isn't visible from outside.

Why are you ignoring the fact that your optimisations can still be added
and be effective?  I already suggested - we can add a flag to indicate that
the caller does not care about the result in the memory store.  Moreover,
the usual byte-code produced by tcpdump/pcap does not even use the memory
store so you optimisations would most of the time be applicable anyway!

> This discussion is going to nowhere. At this point, someone from
> outside should review our opinions and help us to make a decision.
> 
> Alex

-- 
Mindaugas