On Sat, 23 Dec 2023 at 23:25, Yuval El-Hanany <yuvale@xxxxxxxxxxx> wrote: > > Hi, > I’m designing a POC to port a large application from DPDK to XDP. Switching ingressing packets between different processes is part of the core concept of the POC. I saw a question in the Q&A of AF_XDP but the question and answer seem a bit mismatched. The question is about switching umems in copy mode and the answer is generic about switching queues. > > Q: Can I use the XSKMAP to implement a switch between different umems in copy mode? > A: The short answer is no, that is not supported at the moment. The XSKMAP can only be used to switch traffic coming in on queue id X to sockets bound to the same queue id X. The XSKMAP can contain sockets bound to different queue ids, for example X and Y, but only traffic goming in from queue id Y can be directed to sockets bound to the same queue id Y. In zero-copy mode, you should use the switch, or other distribution mechanism, in your NIC to direct traffic to the correct queue id and socket. > > My follow up question is whether this applies if I use a shared umem to all queues and devices. Obviously, it does not apply in user mode, as it’s possible to send the packets to any device and queue sharing the umem. Is it impossible to send packets to different queues even if they share umem in the XDP program using the XSKMAP? Is this a hard limit or a safety measure, that may be lifted using some kernel patch? For the POC, the limitation may fail the whole port. I've tried to switch packets between queues in a simple single process application in skb mode with a shared umem and indeed it seems the packets did not reach their destination. Sorry for the delay, but now I am finally back from the holidays. In zero-copy mode, it should be possible to lift this restriction when the umem is shared between different netdevs and queue ids. My guess is that this restriction in the code is there from before the time the shared umem concept was introduced and it was not lifted when I introduced that. The only complication I can see is that in user-space, you do not know from what fill ring the buffer came from. So a simple scheme such as: "after processing a buffer from the Rx ring, return the buffer to the corresponding fill ring" does not work anymore. But that is easy to solve, so should not be a problem. Do you want to take a stab at a patch or do you prefer me to do it? There is also the case of copy-mode that we should support, but we might get that for free as it amounts to the same thing when the umem is shared. However, it is also possible to support your use case (in copy-mode) when the umem is not shared as we are copying the packet anyway in copy-mode. Just have to pick the correct umem as the destination. > > Thanks, > Yuval.
|