netdev - Re: [PATCH bpf-next 03/12] net: Add IFLA_XDP_EGRESS for XDP programs in the egress path

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]

Date:   Sat, 1 Feb 2020 09:08:00 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     David Ahern <dsahern@...il.com>, David Ahern <dsahern@...nel.org>,
        netdev@...r.kernel.org, prashantbhole.linux@...il.com,
        jasowang@...hat.com, davem@...emloft.net, jbrouer@...hat.com,
        mst@...hat.com, toshiaki.makita1@...il.com, daniel@...earbox.net,
        john.fastabend@...il.com, ast@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, andriin@...com,
        David Ahern <dahern@...italocean.com>
Subject: Re: [PATCH bpf-next 03/12] net: Add IFLA_XDP_EGRESS for XDP
 programs in the egress path

On Sat, 01 Feb 2020 17:24:39 +0100, Toke Høiland-Jørgensen wrote:
> > I'm weary of partially implemented XDP features, EGRESS prog does us
> > no good when most drivers didn't yet catch up with the REDIRECTs.  
> 
> I kinda agree with this; but on the other hand, if we have to wait for
> all drivers to catch up, that would mean we couldn't add *anything*
> new that requires driver changes, which is not ideal either :/

If EGRESS is only for XDP frames we could try to hide the handling in
the core (with slight changes to XDP_TX handling in the drivers),
making drivers smaller and XDP feature velocity higher.

I think loading the drivers with complexity is hurting us in so many
ways..

> > And we're adding this before we considered the queuing problem.
> >
> > But if I'm alone in thinking this, and I'm not convincing anyone we
> > can move on :)  
> 
> I do share your concern that this will end up being incompatible with
> whatever solution we end up with for queueing. However, I don't
> necessarily think it will: I view the XDP egress hook as something
> that in any case will run *after* packets are dequeued from whichever
> intermediate queueing it has been through (if any). I think such a
> hook is missing in any case; for instance, it's currently impossible
> to implement something like CoDel (which needs to know how long a
> packet spent in the queue) in eBPF.

Possibly 🤔 I don't have a good mental image of how the XDP queuing
would work.

Maybe once the queuing primitives are defined they can easily be
hooked into the Qdisc layer. With Martin's recent work all we need is 
a fifo that can store skb pointers, really...

It'd be good if the BPF queuing could replace TC Qdiscs, rather than 
layer underneath.