Prashant Batra <prbatra.mail@xxxxxxxxx> writes: > Just to get your expert opinion on this, I am sharing at a very high > level what my objectives are- > For Rx handling: > Demultiplex the packets received on the physical/bond interface based > on the packet's src + dst combination and direct it to the process > (Pn) handling that src + dst packets. > a) One way of doing this is to pick all packets in userspace in a > central process (Pc) using AF_XDP socket (ZC with phy device and > XDP_DRV with bond) and then Pc passes it using shared memory to the > correct process (Pn) for further handling. > ens1f0/bond (AF_XDP) -> Pc -> Pn > b) The other way is to run a xdp code attached to the phy/bond > device which based on the src + dst redirects the packets to the veth > pair (one per process Pn). The packet is then forwarded to the other > end of the veth-pair over which there is an AF_XDP socket opened.The > advantage here is that the packet demultiplex happens in the kernel > and there is no Pc process needed. > ens1f0/bond (XDP_REDIRECT_IF) ->vethext -> vethint ( AF_XDP) -> Pn Adding in Jesper, Lorenzo and Maryam, as we've had various discussions around improving AF_XDP support in containers, which seems to have some overlap with your use case. Basically, what we have been discussing is that your (b) approach has many desirable properties, also from a container management PoV, and we believe it is possible to make it perform reasonably well on both RX and TX. It's most likely never going to be completely zero-copy because of the veth traversal, but we should be able to get it down to a single copy at least. However, there is some work to be done before we can realise this potential; but having more people interested in the use case may help here :) > Regarding netkit, I don't see much documentation or samples available > except the selftest available in the kernel code. If you have or know > of some samples that might fit in the above requirements that will > surely help. Does it fit in the above requirement? Netkit does not support XDP at all, and I doubt it ever will. Rather, it is meant for optimising the use of BPF in the kernel stack (skb) path, so it doesn't sound like it's a good fit for your use case if you want to go directly from XDP to userspace. -Toke
|