Re: BPF memstore and bpf_validate_ext()

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

Mindaugas Rasiukevicius wrote:
> > > 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.

Well, if it wasn't needed for many year in bpf, why do we need it now? ;-)

To answer your question about a program that needs some values stored,
you want a protocol to pass some values from the host C environment to
embedded BPF environment. You do it in a very ad-hoc manner. It's
not possible to say by looking at bpf program which memwords are passed
from outside and which are really internal.

BPF is a language and all its extensions should be designed with
this in mind.

> I have already explained the benefits of the external memory store in this
> thread (simple, straightforward way to pass values and have their cache).
> Your main argument seems to be that the external memstore makes it more
> difficult for bpfjit to optimise certain corner cases (which, as been
> pointed out, are not common).

Well, I was arguing about performance because you were concerned about
performance of your bpf programs.

Your solution lacks a concept. You're mixing things together without
bothering much about how will they interact to achieve a common
goal. I already pointed out that your COP is powerful enough to
copy external data to a memory store. To add to my other point
above, you're mixing local and global memory. Or, if you use an
analogy with Lua (that uses a byte code to interpret program),
there are local and global variables with a very clear distinction
between them. With your proposal, there is no clear distinction
inside bpf program which memory words are internal and which are
external.

Though, I don't think I want to see global memory in bpf.

> Given that BPF did not have JIT compiler for many years and even a very
> simplistic JIT compilation is a huge win - I do not understand why do you
> consider corner case optimisations as a higher value than the benefits
> provided by the external memstore.

I personally see no benefits in external memstore at all. You can copy
external data with a special copfunc.

> > 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.
> 
> That is wonderful, but not the point..

Ok, let me make a point them. If you want to make significant changes to
bpf, you'd better start from scrach and design whatever you want. I'd be
easier than arguing about bpf changes forever.

Alex