Re: BPF memstore and bpf_validate_ext()

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

Alexander Nasonov <alnsn%yandex.ru@localhost> 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