netdev - Re: [RFC Patch net-next] net_sched: introduce eBPF based Qdisc

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: <CAADnVQK8Q6C=yq7qLaibwGDV0YuMP2DywjKfJCXr6Z1p17-tHg@mail.gmail.com>
Date:   Wed, 1 Sep 2021 11:03:59 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Martin KaFai Lau <kafai@...com>
Cc:     Cong Wang <xiyou.wangcong@...il.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        John Fastabend <john.fastabend@...il.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, Cong Wang <cong.wang@...edance.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>
Subject: Re: [RFC Patch net-next] net_sched: introduce eBPF based Qdisc

On Wed, Sep 1, 2021 at 10:46 AM Martin KaFai Lau <kafai@...com> wrote:
> > > Another idea. Rather than work with qdisc objects which creates all
> > > these issues with how to work with existing interfaces, filters, etc.
> > > Why not create an sk_buff map? Then this can be used from the existing
> > > egress/ingress hooks independent of the actual qdisc being used.
> >
> > I agree. In fact, I'm working on doing just this for XDP, and I see no
> > reason why the map type couldn't be reused for skbs as well. Doing it
> > this way has a couple of benefits:
> >
> > - It leaves more flexibility to BPF: want a simple FIFO queue? just
> >   implement that with a single queue map. Or do you want to build a full
> >   hierarchical queueing structure? Just instantiate as many queue maps
> >   as you need to achieve this. Etc.
> Agree.  Regardless how the interface may look like,
> I even think being able to queue/dequeue an skb into different bpf maps
> should be the first thing to do here.  Looking forward to your patches.
>
> >
> > - The behaviour is defined entirely by BPF program behaviour, and does
> >   not require setting up a qdisc hierarchy in addition to writing BPF
> >   code.
> Interesting idea.  If it does not need to use the qdisc object/interface
> and be able to do the qdisc hierarchy setup in a programmable way, it may
> be nice.  It will be useful for the future patches to come with some
> bpf prog examples to do that.

Wow. When core developers think along the same lines and
build/refine the idea together it's simply awesome.