Re: [PATCH bpf-next v2 1/2] libbpf: add support for using AF_XDP sockets

[Daniel Borkmann <daniel@iogearbox.net>]

On 12/13/2018 10:06 AM, Magnus Karlsson wrote:
> On Thu, Dec 13, 2018 at 7:24 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>> On Wed, Dec 12, 2018 at 02:09:48PM +0100, Magnus Karlsson wrote:
>>> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
>>> index cd02cd4..ae4cc0d 100644
>>> --- a/tools/lib/bpf/libbpf.map
>>> +++ b/tools/lib/bpf/libbpf.map
>>> @@ -121,6 +121,15 @@ LIBBPF_0.0.1 {
>>>               libbpf_prog_type_by_name;
>>>               libbpf_set_print;
>>>               libbpf_strerror;
>>> +             xsk__peek_cons;
>>> +             xsk__release_cons;
>>> +             xsk__reserve_prod;
>>> +             xsk__submit_prod;
>>> +             xsk__get_data;
>>> +             xsk__create_umem;
>>> +             xsk__create_xdp_socket;
>>> +             xsk__delete_umem;
>>> +             xsk__delete_xdp_socket;
>>>       local:
>>
>> I fully support the idea to provide common library for AF_XDP
>> that is easily available in the distros.

+1

>> The main question is whether AF_XDP warrants its own lib or
>> piggy back on libbpf effort is acceptable.
>>
>> Do you think above set of APIs will be enough for foreseeable
>> future or this is just a beginning?
> 
> This should be enough for the foreseeable future, maybe with the
> addition of the two higher level data plane functions xsk__recvmsg and
> xsl__sendmsg that was mentioned in the cover letter. My intention with
> this functionality is not to create another DPDK (there is already
> one, so no reason to reinvent it). I just want to lower the bar of
> entry for using AF_XDP and to stop people copying the code in the
> sample application. To use AF_XDP you need libbpf anyway, so I think
> it is a good fit for it. The intention is to keep this functionality
> lean and mean.

+1

>> If above is enough then it falls into XDP category. libbpf
>> already has minimal support for XDP and AF_XDP fits right in.

Agree, I think given we have XDP support in there already, it would
fit to complement the lib with AF_XDP helpers to set up and get raw
access to the pkt data.

Any framework on top of this providing helper functions to develop
applications should be out of scope here and subject to other libraries,
DPDK and whatnot.

>> But if AF_XDP will keep growing a lot then it would make
>> sense to keep the functionality in a separate library
>> that minimally depends on libbpf.