[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BPF memstore and bpf_validate_ext()
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.
Main Index |
Thread Index |