Re: Talk about AF_XDP support multithread concurrently receive packet

["Björn Töpel" <bjorn.topel@gmail.com>]

On Tue, 23 Jun 2020 at 08:21, Yahui Chen <goodluckwillcomesoon@gmail.com> 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.