netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH bpf-next 0/2] libbpf: adding af_xdp support
@ 2018-12-10 15:34 Magnus Karlsson
  2018-12-10 15:34 ` [PATCH bpf-next 1/2] libbpf: add support for using AF_XDP sockets Magnus Karlsson
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Magnus Karlsson @ 2018-12-10 15:34 UTC (permalink / raw)
  To: magnus.karlsson, bjorn.topel, ast, daniel, netdev, jakub.kicinski,
	bjorn.topel, qi.z.zhang
  Cc: brouer

This patch proposes to add AF_XDP support to libbpf. The main reason for
this is to facilitate writing applications that use AF_XDP by offering
higher-level APIs that hide many of the details of the AF_XDP
uapi. This is in the same vein as libbpf facilitates XDP adoption by
offering easy-to-use higher level interfaces of XDP
functionality. Hopefully this will facilitate adoption of AF_XDP, make
applications using it simpler and smaller, and finally also make it
possible for applications to benefit from optimizations in the AF_XDP
user space access code. Previously, people just copied and pasted the
code from the sample application into their application, which is not
desirable.

The proposed interface is composed of two parts:

* Low-level access interface to the four rings and the packet
* High-level control plane interface for creating and setting up umems
  and AF_XDP sockets.

The sample program has been updated to use this new interface and in
that process it lost roughly 300 lines of code. I cannot detect any
performance degradations due to the use of this library instead of the
previous functions that were inlined in the sample application. But I
did measure this on a slower machine and not the Broadwell that we
normally use.

Some questions:

* I added a new prefix to libbpf called ''xsk_''. Is this ok, or would
  ''bpf_xsk_'' or just ''bpf_'' be preferable?

* The libbpf internal struct for the rings are exposed in the libbpf.h
  header file for performance reasons as it is important that the
  application writer has full control on where it is allocated, for
  example on the stack or in a struct together with counters that are
  frequently used. Is there some way to achieve this flexibility but
  still hide this struct from the user? This would allow more
  flexibility for future optimizations.

* Is it ok to have static inline functions in this library? They are
  currently static inline for performance reasons, but maybe -flto
  could fix this but not everyone uses this.

* I have included 3 more header files compared to libbpf without AF_XDP
  functionality: barrier.h (for the memory barriers used for correctly
  ordered accesses to the rings) compiler.h (for one unliekly and one
  likely with a tiny performance impact, if any) and list.h (some
  extra functions). What to do with these (and the header files they
  include) as they need to be dual licensed for libbpf.so?

* I bumped the API version to 0.0.2, but do not know if you have
  "released" 0.0.1 yet.

In a future release, I am planning on adding a higher level data plane
interface too. This will be based around recvmsg and sendmsg with the
use of struct iovec for batching, without the user having to know
anything about the underlying four rings of an AF_XDP socket. There
will be one semantic difference though from the standard recvmsg and
that is that the kernel will fill in the iovecs instead of the
application. But the rest should be the same as the libc versions so
that application writers feel at home.

Patch 1: adds af_xdp support in libbpf
Patch 2: updates the xdpsock sample application to use the libbpf functions.

I based this patch set on bpf-next commit 01d3240a04f4 ("media: bpf:
add bpf function to report mouse movement")

Thanks: Magnus


Magnus Karlsson (2):
  libbpf: add support for using AF_XDP sockets
  samples/bpf: convert xdpsock to use libbpf for AF_XDP access

 samples/bpf/xdpsock_user.c        | 584 +++++++++++---------------------------
 tools/include/uapi/linux/if_xdp.h |  78 +++++
 tools/lib/bpf/Build               |   2 +-
 tools/lib/bpf/Makefile            |   5 +-
 tools/lib/bpf/README.rst          |  11 +-
 tools/lib/bpf/libbpf.h            |  93 ++++++
 tools/lib/bpf/libbpf.map          |  12 +
 tools/lib/bpf/xsk.c               | 506 +++++++++++++++++++++++++++++++++
 8 files changed, 868 insertions(+), 423 deletions(-)
 create mode 100644 tools/include/uapi/linux/if_xdp.h
 create mode 100644 tools/lib/bpf/xsk.c

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2018-12-17 12:47 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-10 15:34 [PATCH bpf-next 0/2] libbpf: adding af_xdp support Magnus Karlsson
2018-12-10 15:34 ` [PATCH bpf-next 1/2] libbpf: add support for using AF_XDP sockets Magnus Karlsson
2018-12-12  0:48   ` Daniel Borkmann
2018-12-12  0:57   ` Daniel Borkmann
2018-12-12  1:14   ` Daniel Borkmann
2018-12-12  7:59     ` Magnus Karlsson
2018-12-12  8:08       ` Magnus Karlsson
2018-12-10 15:34 ` [PATCH bpf-next 2/2] samples/bpf: convert xdpsock to use libbpf for AF_XDP access Magnus Karlsson
2018-12-11  0:07   ` Jakub Kicinski
2018-12-12  7:57     ` Magnus Karlsson
2018-12-17 11:07   ` Jesper Dangaard Brouer
2018-12-17 12:47     ` Magnus Karlsson
2018-12-11  0:10 ` [PATCH bpf-next 0/2] libbpf: adding af_xdp support Jakub Kicinski
2018-12-12  0:45   ` Daniel Borkmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).