On 02/21/2019 10:21 AM, Magnus Karlsson wrote: > 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. This interface also loads a simple XDP program > that routes all traffic on a queue up to the AF_XDP socket. > > 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. > > The rings are now called xsk_ring and when a producer operates on > it. It is xsk_ring_prod and for a consumer it is xsk_ring_cons. This > way we can get some compile time error checking that the rings are > used correctly. > > Comments and contenplations: > > * The current behaviour is that the library loads an XDP program (if > requested to do so) but the clean up of this program is left to the > application. It would be possible to implement this cleanup in the > library, but it would require state to be kept on netdev level, > which there is none at the moment, and the synchronization of this > between processes. All this adding complexity. But when we get an > XDP program per queue id, then it becomes trivial to also remove the > XDP program when the application exits. This proposal from Jesper, > Björn and others will also improve the performance of libbpf, since > most of the XDP program code can be removed when that feature is > supported. > > * 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 > Patch 3: Documentation update to help first time users > > Changes v5 to v6: > * Fixed prog_fd bug found by Xiaolong Ye. Thanks! > Changes v4 to v5: > * Added a FAQ to the documentation > * Removed xsk_umem__get_data and renamed xsk_umem__get_dat_raw to > xsk_umem__get_data > * Replaced the netlink code with bpf_get_link_xdp_id() > * Dynamic allocation of the map sizes. They are now sized after > the max number of queueus on the netdev in question.
Looks better, I've applied it to bpf-next, thanks!
