netdev - Re: [PATCH bpf-next v2 1/2] libbpf: add support for using 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181213062319.s7abjni6j2ncpx4q@ast-mbp.dhcp.thefacebook.com>
Date:   Wed, 12 Dec 2018 22:23:21 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Magnus Karlsson <magnus.karlsson@...el.com>
Cc:     bjorn.topel@...el.com, ast@...nel.org, daniel@...earbox.net,
        netdev@...r.kernel.org, jakub.kicinski@...ronome.com,
        bjorn.topel@...il.com, qi.z.zhang@...el.com, brouer@...hat.com
Subject: Re: [PATCH bpf-next v2 1/2] libbpf: add support for using AF_XDP
 sockets

On Wed, Dec 12, 2018 at 02:09:48PM +0100, Magnus Karlsson wrote:
> 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?

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.