netdev - Re: [RFC 2/2] net: bridge: add a software fast-path implementation

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: <e8f1e8f5-8417-84a8-61c3-793fa7803ac6@nbd.name>
Date:   Thu, 10 Feb 2022 17:53:04 +0100
From:   Felix Fietkau <nbd@....name>
To:     Nikolay Aleksandrov <nikolay@...dia.com>, netdev@...r.kernel.org
Subject: Re: [RFC 2/2] net: bridge: add a software fast-path implementation

On 10.02.22 16:02, Nikolay Aleksandrov wrote:
> Hi Felix,
> that looks kind of familiar. :) I've been thinking about a similar optimization for
> quite some time and generally love the idea, but I thought we'd allow this to be
> implemented via eBPF flow speedup with some bridge helpers. There's also a lot of low
> hanging fruit about optimizations in bridge's fast-path.
> 
> Also from your commit message it seems you don't need to store this in the bridge at
> all but can use the notifications that others currently use and program these flows
> in the interested driver. I think it'd be better to do the software flow cache via
> ebpf, and do the hardware offload in the specific driver.
To be honest, I have no idea how to handle this in a clean way in the 
driver, because this offloading path crosses several driver/subsystem 
boundaries.

Right now we have support for a packet processing engine (PPE) in the 
MT7622 SoC, which can handle offloading IPv4 NAT/routing and IPv6 routing.
The hardware can also handle forwarding of src-mac/destination-mac 
tuples, but that is currently unused because it's not needed for 
ethernet-only forwarding.

When adding WLAN to the mix, it gets more complex. The PPE has an output 
port that connects to a special block called Wireless Ethernet Dispatch, 
which can be configured to intercept DMA between the WLAN driver (mt76) 
and a PCIe device with MT7615 or MT7915 in order to inject extra packets.

I already have working NAT/routing offload support for this, which I 
will post soon. In order to figure out the path to WLAN, the offloading 
code calls the .ndo_fill_forward_path op, which mac80211 supports.
This allows the mt76 driver to fill in required metadata which gets 
stored in the PPE flowtable.

On MT7622, traffic can only flow from ethernet to WLAN in this manner, 
on newer SoCs, offloading can work in the other direction as well.

So when looking at fdb entries and flows between them, the ethernet 
driver will have to figure out:
- which port number to use in the DSA tag on the ethernet side
- which VLAN to use on the ethernet side, with the extra gotcha that 
ingress traffic will be tagged, but egress won't
- which entries sit behind mac80211 vifs that support offloading through 
WED.
I would also need to add a way to push the notifications through DSA to 
the ethernet driver, because there is a switch inbetween that is not 
involved in the offloading path (PPE handles DSA tagging/untagging).

By the way, all of this is needed for offloading a fairly standard 
configuration on these devices, so not just for weird exotic settings.

If I let the bridge code tracks flows, I can easily handle this by using 
the same kind of infrastructure that netfilter flowtable uses. If I push 
this to the driver, it becomes a lot more complex and messy, in my 
opinion...

- Felix