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: <bc499a39-64b9-ceb4-f36f-21dd74d6272d@nvidia.com>
Date:   Thu, 10 Feb 2022 17:02:06 +0200
From:   Nikolay Aleksandrov <nikolay@...dia.com>
To:     Felix Fietkau <nbd@....name>, <netdev@...r.kernel.org>
Subject: Re: [RFC 2/2] net: bridge: add a software fast-path implementation

On 10/02/2022 16:24, Felix Fietkau wrote:
> This opt-in feature creates a per-port cache of dest_mac+src_mac+vlan tuples
> with enough information to quickly push frames to the correct destination port.
> It can be enabled per-port
> 
> Cache entries are automatically created when a skb is forwarded from one port
> to another, and only if there is room and both ports have the offload flag set.
> 
> Whenever a fdb entry changes, all corresponding cache entries associated with
> it are automatically flushed.
> 
> In my test on MT7622 when bridging 1.85 Gbit/s from Ethernet to WLAN, this
> significantly improves bridging performance, especially with VLAN filtering
> enabled:
> 
> CPU usage:
> - no offload, no VLAN: 79%
> - no offload, VLAN: 84%
> - offload, no VLAN: 73-74%
> - offload, VLAN: 74%
> 
> MT7622 has support for hardware offloading of packets from LAN to WLAN, both
> routed and bridged. For bridging it needs source/destination MAC address entries
> like the ones stored in this offload cache. This code will be extended later
> in order to create appropriate flow_offload rules to handle this
> 
> Signed-off-by: Felix Fietkau <nbd@....name>
> ---
>  include/linux/if_bridge.h       |   1 +
>  include/uapi/linux/if_link.h    |   3 +
>  net/bridge/Kconfig              |  10 +
>  net/bridge/Makefile             |   1 +
>  net/bridge/br.c                 |   8 +
>  net/bridge/br_device.c          |   4 +
>  net/bridge/br_fdb.c             |  20 +-
>  net/bridge/br_forward.c         |   3 +
>  net/bridge/br_if.c              |   4 +
>  net/bridge/br_input.c           |   5 +
>  net/bridge/br_netlink.c         |  31 ++-
>  net/bridge/br_offload.c         | 466 ++++++++++++++++++++++++++++++++
>  net/bridge/br_private.h         |  30 +-
>  net/bridge/br_private_offload.h |  53 ++++
>  net/bridge/br_stp.c             |   3 +
>  net/bridge/br_vlan_tunnel.c     |   3 +
>  net/core/rtnetlink.c            |   2 +-
>  17 files changed, 641 insertions(+), 6 deletions(-)
>  create mode 100644 net/bridge/br_offload.c
>  create mode 100644 net/bridge/br_private_offload.h
> 

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.

I can't do a thorough review of the patch right now and obviously it will have to be
broken up in smaller pieces. When I get a chance I'll comment on the details.

Thank you,
 Nik