[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BPF memstore and bpf_validate_ext()
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?
Main Index |
Thread Index |