On 10/20/21 2:54 PM, Toke Høiland-Jørgensen wrote: >> Sure, but I'm not sure I understand the use case. >> >> Insertion at XDP layer turns off netfilters NAT capability, so its >> incompatible with the classic forwarding path. >> >> If thats fine, why do you need to insert into the conntrack table to >> begin with? The entire infrastructure its designed for is disabled... > One of the major selling points of XDP is that you can reuse the > existing kernel infrastructure instead of having to roll your own. So > sure, one could implement their own conntrack using BPF maps (as indeed, > e.g., Cilium has done), but why do that when you can take advantage of > the existing one in the kernel? Same reason we have the bpf_fib_lookup() > helper... > Exactly, and a key point is that it allows consistency between XDP fast path and full stack slow path. e.g., the BPF program is removed or defers a flow to full stack for some reason.
