On Tue, 23 Jun 2020 at 08:21, Yahui Chen <goodluckwillcomesoon@xxxxxxxxx> wrote: > > I have make an issue for the libbpf in github, issue number 163. > > Andrii suggest me sending a mail here. So ,I paste out the content of the issue: > Yes, and the xdp-newsbies is an even better list for these kinds of discussions (added). > Currently, libbpf do not support concurrently receive pkts using AF_XDP. > > For example: I create 4 af_xdp sockets on nic's ring 0. Four sockets > receiving packets concurrently can't work correctly because the API of > cq `xsk_ring_prod__reserve` and `xsk_ring_prod__submit` don't support > concurrence. > In other words, you are using shared umem sockets. The 4 sockets can potentially receive packets from queue 0, depending on how the XDP program is done. > So, my question is why libbpf was designed non-concurrent mode, is the > limit of kernel or other reason? I want to change the code to support > concurrent receive pkts, therefore I want to find out whether this is > theoretically supported. > You are right that the AF_XDP functionality in libbpf is *not* by itself multi-process/thread safe, and this is deliberate. From the libbpf perspective we cannot know how a user will construct the application, and we don't want to penalize the single-thread/process case. It's entirely up to you to add explicit locking, if the single-producer/single-consumer queues are shared between threads/processes. Explicit synchronization is required using, say, POSIX mutexes. Does that clear things up? Cheers, Björn > Thx.
|