Re: BPF memstore and bpf_validate_ext()

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

Alexander Nasonov <alnsn%yandex.ru@localhost> wrote:
> 
> Well, if it wasn't needed for many year in bpf, why do we need it now? ;-)
> 

Because it was decided to use BPF byte-code for more applications and that
meant there is a need for improvements.  It is called evolution. :)

> 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.

We are talking about byte-code i.e. quite low level environment.  The
protocol (contract) is specified at the caller level.  Can you explain
what kind of generic protocol do you expect to see?  Let me put it this
way - what *problem* are you trying to solve?

> It's
> not possible to say by looking at bpf program which memwords are passed
> from outside and which are really internal.

How is it different when using BPF coprocessor?  It is as clear (or not)
as using the external memory store.  It is a contract between the caller
and the BPF program.

> 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.

Huh?  What does it have to do with local and global variables?  We barely
have a concept of variable.  We are discussing very simple byte-code which
is not even Turing-complete.  It is not Lua, it is not Haskell, it is tiny
assembly language.  I am all for well-thought abstractions and interfacing,
but how far do you want to go in abstracting 16 words?

I have been trying to figure out what existing or future practical problems
you are trying to solve?  Not metaphysical use cases or fantasy languages
based on BPF byte-code.. they do not exist, they make no sense.  Sometimes
array is just an array, not an object.  The sword is double-edged and the
other edge is called over-engineering.

It is disappointing that we are going ad infinitum..

-- 
Mindaugas