Alexander Nasonov <[email protected]> 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. -- Mindaugas
