[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BPF memstore and bpf_validate_ext()
Alexander Nasonov <alnsn%yandex.ru@localhost> wrote:
> 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?
Including the BPF programs which do not use COP, yes.
> > 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.
Well, sljit is what we've got. I would think it can do nearly as good
as manual crafting if we cover the main cases based on Pareto principle.
> > 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.
For this particular case - yes, correct.
> Except of course you may run out or memwords one day and you want
> to have BPF_COP as a fallback.
I still need BPF_COP for other tasks (e.g. NPF_COP_TABLE). Running out
of words is unlikely, but COP can certainly be used to handle that too.
Main Index |
Thread Index |