Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > This helps gradually moving towards move epbf for those that > > still heavily rely on the classic forwarding path. > > No one is using it. > If it was, we would have seen at least one bug report over > all these years. We've seen none. Err, it IS used, else I would not have sent this patch. > very reasonable early on and turned out to be useless with > zero users. > BPF_PROG_TYPE_SCHED_ACT and BPF_PROG_TYPE_LWT* > are in this category. I doubt it had 0 users. Those users probably moved to something better? > As a minimum we shouldn't step on the same rakes. > xt_ebpf would be the same dead code as xt_bpf. Its just 160 LOC or so, I don't see it has a huge technical debt. > > If you are open to BPF_PROG_TYPE_NETFILTER I can go that route > > as well, raw bpf program attachment via NF_HOOK and the bpf dispatcher, > > but it will take significantly longer to get there. > > > > It involves reviving > > https://lore.kernel.org/netfilter-devel/20211014121046.29329-1-fw@xxxxxxxxx/ > > I missed it earlier. What is the end goal ? Immediate goal: get rid of all indirect calls from NF_HOOK() invocations. Its about 2% speedup in my tests (with connection tracking+defrag enabled). This series changes prototype of the callbacks to int foo(struct *), so I think it would be possible to build on this and allow attaching raw bpf progs/implement what is now a netfilter kernel module as a bpf program. I have not spent time on this so far though, so I don't know yet how the "please attach prog id 12345 at FORWARD with prio 42" should be done. > Optimize nft run-time with on the fly generation of bpf byte code ? This could be done too, so far this JITs nf_hook_slow() only. The big question for nft run-time would be how and where to do the JIT translation. I think that "nft run time jit" would be step 3, after allowing (re)implementation of netfilter modules via bpf programs.
