Mindaugas Rasiukevicius wrote: > Alexander Nasonov <[email protected]> wrote: > > My point is that you mix "argument pack" with something else. They > > should be separeted. > > The external memory store can be used as an argument (and the initial > values determined as proposed in this thread). If you want, we can pass > it as a third argument, I just think it is a pointless indirection level. > Would even need extra wrapping i.e. more work in bpfjit, but if you want > that separated - fine.
I'll tell you more. Mixing mem with arguments will not only save me one register/one indirection level but it will allow to use memory addressing. It's very attractive solution from a performance perspective. But it's clearly a hack and I don't want to have hacks in public API. > > I already offered to support SLJIT_FAST_CALL copfuncs in bpfjit. > > They're much faster than regular copfuncs. But that's mean you > > will need to emit sljit code and you will have a limited number of > > sljit registers and all other limitations of sljit. You still should > > be able to copy data from auxiliary argument to memstore and you > > can do it quite fast. <...> > > That is great, but we are going circles here. If a program just needs > some values stored in the memory store - why would you create a COP to > get few integers instead of simply letting the caller to pass them. It > is the thing which actually has those numbers. What if your program "just needs" something else? Does it mean we have to add a new feature to bpf? No. We have to stop somewhere. BPF_COP is powerful enough for getting external data. It's a bit slower but I can give you SLJIT_FAST_CALL interface. If it's still slow for you, you should stop using sljit and consider other alternatives. > > It's easy to > > suggest to have a flag but it's actually a lot or work. You need to > > write several lines of C code to generate a single instruction. > > The flag would basically say "treat the memstore as internal i.e. just > do all the optimisations, because I assure there are no side effects". > It is a green light for what you said you already want to implement. > That would be one-liner check or I miss something? Ok, with my recent change on github, it's indeed one-line change but having two different modes can introduce subtle bugs. If you forget to set the mode properly, you may have a situation when your memory is in a bad state only for packets of length 131 (or whatever) and it's consistent for all other lengths. I'm as a maintainer of bpfjit is responsible for a robust public interface. Alex
