On 12/13/2018 10:06 AM, Magnus Karlsson wrote:

On Thu, Dec 13, 2018 at 7:24 AM Alexei Starovoitov
[off-list ref] wrote:

quoted

On Wed, Dec 12, 2018 at 02:09:48PM +0100, Magnus Karlsson wrote:

quoted

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

quoted

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

quoted

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.

quoted

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.