netdev - Re: [PATCH RFC bpf-next 0/7] Add bpf

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: <bd18943b-8a0e-be8c-6a99-17f7dfdd3bc4@iogearbox.net>
Date:   Wed, 16 Jun 2021 01:07:23 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Jamal Hadi Salim <jhs@...atatu.com>,
        Kumar Kartikeya Dwivedi <memxor@...il.com>
Cc:     Cong Wang <xiyou.wangcong@...il.com>, bpf <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>, Vlad Buslov <vladbu@...dia.com>,
        Jiri Pirko <jiri@...nulli.us>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, Joe Stringer <joe@...ium.io>,
        Quentin Monnet <quentin@...valent.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Marcelo Ricardo Leitner <mleitner@...hat.com>
Subject: Re: [PATCH RFC bpf-next 0/7] Add bpf_link based TC-BPF API

On 6/13/21 11:10 PM, Jamal Hadi Salim wrote:
> On 2021-06-13 4:34 p.m., Kumar Kartikeya Dwivedi wrote:
>> On Mon, Jun 14, 2021 at 01:57:16AM IST, Jamal Hadi Salim wrote:
[...]
>> Right, also I'm just posting so that the use cases I care about are clear, and
>> why they are not being fulifilled in some other way. How to do it is ofcourse up
>> to TC and BPF maintainers, which is why I'm still waiting on feedback from you,
>> Cong and others before posting the next version.
> 
> I look at it from the perspective that if i can run something with
> existing tc loading mechanism then i should be able to do the same
> with the new (libbpf) scheme.

The intention is not to provide a full-blown tc library (that could be subject to a
libtc or such), but rather to only have libbpf abstract the tc related API that is
most /relevant/ for BPF program development and /efficient/ in terms of execution in
fast-path while at the same time providing a good user experience from the API itself.

That is, simple to use and straight forward to explain to folks with otherwise zero
experience of tc. The current implementation does all that, and from experience with
large BPF programs managed via cls_bpf that is all that is actually needed from tc
layer perspective. The ability to have multi programs (incl. priorities) is in the
existing libbpf API as well.

Best,
Daniel