On Thu, Dec 13, 2018 at 7:24 AM Alexei Starovoitov
<alexei.starovoi...@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.
>
> 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.
> If above is enough then it falls into XDP category. libbpf
> already has minimal support for XDP and AF_XDP fits right in.
>
> 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.
>
