Alexander Nasonov al...@yandex.ru wrote:
Mindaugas Rasiukevicius wrote:
Also, it was you who proposed sljit.
Proposed for what? I implemented bpfjit using sljit if that's what
you mean. I offered you a help with implementing jit compiler for
npfcode. It was your idea to add COP/COPX and I agreed to implement
a support for it in bpfjit. I never agreed on implementing external
memory.
Fair enough. I still lack clear understanding why are you unhappy with
the external memory store..
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?
I don't have any application in mind but I don't understand why are you
pushing two extentions to bpf solely to get performance benefit for
your cases and you don't care that bpf looses performance even if there
are no cop instructions in a program at all.
I *do* care about performance of regular BPF usage i.e. tcpdump/libpcap.
However, I have been trying to explain that it is trivial to avoid the
performance penalty.. perhaps I miss something, but you did not explain
why is it problematic.
We can pass the memstore pointer as a separate argument (it would be
three arguments, fine for sljit), but what's the point..
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.
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.
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.
It straightforward, it is simpler, it is faster, and it does not make
the performance suffer for other programs. BPF_COP optimisations are
brilliant, but.. we are talking about different issue.
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?
I don't want to maintain two different modes of code generation.
If you want this flag, go ahead, write the code, write the tests
and everyone will be happy.
I was simply trying to make suggestions which would make your life
easier, certainly not harder. Alternatively, I can write patches.
--
Mindaugas
