Hello,playing with xdpbridge https://github.com/ilejn/xdpbridge/ I've observed a limitation which is serious for me.
xdpbridge is basically a combination of xdp_redirect_map sample (world=>client path) and slightly more advanced l2fwd mode of xdpsock (client=>world path), where AF_XDP sockets are bound to two different interfaces (vanilla l2fwd mode uses same interface as ingress and egress) and where multithreading is supported.
xdpbridge sets options for client and egress interfaces independently.So, setting zerocopy bind flag for world interface (-z command line parameter) prevents this interface from working as ingress for world=>client path, although different queues are used. No errors, just no data transfer.
It would be nice to understand if this issue fundamental or specific for the kernel (5.0.0-31-generic #33~18.04.1-Ubuntu) or card (Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)) or driver.
Or, may be, it is just my mistake. I do appreciate any comments or suggestions. On 10.09.2019 17:38, Toke Høiland-Jørgensen wrote:
Ilya Goslhtein <ilejn@xxxxxxxxx> writes:Hello Toke, thanks for the response. I do not think that it is the case. The interface I am trying to share is outgoing for xdpbridge and incoming for xdp_bridge_map. xdpbridge does not load xdp program for outgoing interface (while loads for incoming). xdp_bridge_map loads dummy XDP program for outgoing redirect, while it is Ok if it is already exists. It seems that if I use different queues for incoming and outgoing packets, everything is Ok, while I am not 100% sure yet. Does it look realistic?Oh, right, yeah, the AF_XDP socket will need to configure a hardware queue to use; depending on your hardware, that could be incompatible with running a regular XDP program on the same hardware queue. Incidently, we are working on a way to make this work better; talk starts in five minutes at LPC: https://linuxplumbersconf.org/event/4/contributions/462/ -Toke
-- Best regards, Ilya Golshtein
|