Re: BPF memstore and bpf_validate_ext()

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

Mindaugas Rasiukevicius wrote:
> It is an argument/context to be passed for the BPF coprocessors (only).
> We want to let the *caller* of bpf_filter() (or JIT-compiled BPF program)
> pass some values to the BPF *program* using the memory store.  It allows
> us to re-use the memstore as a cache.

Are you saying that we want to pass some values to bpf programs that
don't use cop?

> Isn't it only i386?  On amd64 or RISC archs it would mean just an extra
> fetch, right?  I am not sure what is (or would be) the current register
> allocation in the latest bpfjit snapshot.  Still, having memstore as a
> cache ought to win way more compared to the extra fetches or push/pops.

You can win even more if you switch to manually crafted assembly or
build a sophisticated JIT language tailored for NPF. You don't have
to use bpfjit at all.

> Right, but this is for the coprocessors.  I am fine with it (as we talked
> privately, I was considering to propose a very similar API), but it seems
> that bpf_set_initwords() already *efficiently* covers all my cases.  With
> this change, I will actually be able to remove NPF_COP_L3!

I think I know what are you getting at.

In your case BPF_COP is always the first instruction (or in the
first linear block). Because it's the first and it's a function
call, it can be moved outside of bpf program and inlined.

If this is the case, you don't need BPF_COP at all.

Except of course you may run out or memwords one day and you want
to have BPF_COP as a fallback.

Is the above correct?

Alex