netdev - Re: [PATCH bpf-next v6 0/3] libbpf: adding AF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2f247230-b99e-c13f-3c64-3835456e4f01@iogearbox.net>
Date:   Mon, 25 Feb 2019 23:59:56 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Magnus Karlsson <magnus.karlsson@...el.com>, bjorn.topel@...el.com,
        ast@...nel.org, netdev@...r.kernel.org,
        jakub.kicinski@...ronome.com, bjorn.topel@...il.com,
        qi.z.zhang@...el.com
Cc:     brouer@...hat.com, xiaolong.ye@...el.com
Subject: Re: [PATCH bpf-next v6 0/3] libbpf: adding AF_XDP support

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!