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

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.

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.