Resending the following email to the XDP Newbies mailing list since it was rejected due to HTML contents (I've switched email clients and forgot to disable HTML, I apologize). Hey everyone, I was wondering if there was an update to this. I'm currently running into the same issue with a similar setup. When running the XDP program on a bonding device via native mode, packets redirected to the AF_XDP sockets with `bpf_redirect_map()` inside the XDP program do not make it to the AF_XDP sockets. Switching between zero copy and copy mode does not make a difference along with setting the need wakeup flag. I've tried the latest mainline kernel `6.8.1-060801`, but that did not make a difference. If the XDP program is attached with SKB mode, packets do show up on the AF_XDP sockets as mentioned in this thread already. While I haven't confirmed it on my side, I'm assuming the `xsk_rcv_check()` function is the issue here. I'm unsure if skipping this check for the time being would work for my needs, but I'm hoping a better solution will be implemented to the mainline kernel. I also saw there was another similar issue on this mailing list with the title "Switching packets between queues in XDP program". However, judging from the last reply in that thread, the fix implemented wouldn't help with the bonding driver. Any help is appreciated and thank you for your time! On Mon, Mar 18, 2024 at 2:33 PM Christian Deacon <christian.m.deacon@xxxxxxxxx> wrote: > > Hey everyone, > > I was wondering if there was an update to this. I'm currently running into the same issue with a similar setup. > > When running the XDP program on a bonding device via native mode, packets redirected to the AF_XDP sockets with `bpf_redirect_map()` inside the XDP program do not make it to the AF_XDP sockets. Switching between zero copy and copy mode does not make a difference along with setting the need wakeup flag. > > I've tried the latest mainline kernel `6.8.1-060801`, but that did not make a difference. If the XDP program is attached with SKB mode, packets do show up on the AF_XDP sockets as mentioned in this thread already. > > While I haven't confirmed it on my side, I'm assuming the `xsk_rcv_check()` function is the issue here. I'm unsure if skipping this check for the time being would work for my needs, but I'm hoping a better solution will be implemented to the mainline kernel. > > I also saw there was another similar issue on this mailing list with the title "Switching packets between queues in XDP program". However, judging from the last reply in that thread, the fix implemented wouldn't help with the bonding driver. > > Any help is appreciated and thank you for your time! > > On Fri, Jan 19, 2024 at 8:04 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> 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 >> >>
|