Alexander Nasonov <[email protected]> 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
