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:   Sun, 2 Feb 2020 11:31:52 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     David Ahern <dsahern@...il.com>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        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
Subject: Re: [PATCH bpf-next 03/12] net: Add IFLA_XDP_EGRESS for XDP
 programs in the egress path

On Sun, 2 Feb 2020 10:43:58 -0700, David Ahern wrote:
> you are making a lot of assumptions and frankly it's the 'c' word
> (complex) that I want to avoid. I do not believe in the OVS style of
> packet processing - one gigantic program with a bunch of logic and data
> driven flow lookups that affect every packet. I prefer simple, singly
> focused programs logically concatenated to make decisions. Simpler
> management, simpler lifecycle. The scope, scale and lifecycle management
> of VMs/containers is just as important as minimizing the cycles spent
> per packet. XDP in the Tx path is a missing primitive to make life simple.
> 
> As an example, the program on the ingress NICs to the host can be
> nothing more than a demux'er - use the ethernet header and vlan
> (preferably with vlan offload enabled) to do a <vlan,mac> lookup. No
> packet parsing at all at this level. The lookup returns an index of
> where to redirect the packet (e.g., the tap device of a VM). At the same
> time, packets can hit the "slow path" - processing support from the full
> stack when it is needed and still packets end up at the tap device. *IF*
> there is an ingress ACL for that tap device managed by the host, it can
> exist in 1 place - a program and map attached to the tap device limited
> to that tap device's networking function (VMs can have multiple
> connections to different networks with different needs at this point),
> and the program gets run for both XDP fast path and skb slow path.

I think our perspectives will be difficult to reconcile.

My reading is that you look at this from slow software device
perspective. Of which there are few (and already loaded with hacks).
And you want the control plane to be simple rather than performance.

I look at this from HW driver perspective of which there are many.
Saying that it's fine to load TX paths of all drivers with extra 
code, and that it's fine to effectively disable SG in the entire 
system just doesn't compute.

Is that a fair summary of the arguments?