netdev - Re: [PATCH v5 net-next 0/5] Allow TX forwarding for the software bridge data path to be offloaded to capable devices

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] [day] [month] [year] [list]

Message-Id: <162705540587.23511.775470565736247308.git-patchwork-notify@kernel.org>
Date:   Fri, 23 Jul 2021 15:50:05 +0000
From:   patchwork-bot+netdevbpf@...nel.org
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     netdev@...r.kernel.org, kuba@...nel.org, davem@...emloft.net,
        andrew@...n.ch, f.fainelli@...il.com, vivien.didelot@...il.com,
        jiri@...nulli.us, idosch@...sch.org, tobias@...dekranz.com,
        roopa@...dia.com, nikolay@...dia.com, stephen@...workplumber.org,
        bridge@...ts.linux-foundation.org, grygorii.strashko@...com,
        kabel@...ckhole.sk, dqfext@...il.com, vkochan@...vell.com,
        tchornyi@...vell.com, ioana.ciornei@....com,
        lars.povlsen@...rochip.com, Steen.Hegelund@...rochip.com,
        UNGLinuxDriver@...rochip.com, claudiu.manoil@....com,
        alexandre.belloni@...tlin.com
Subject: Re: [PATCH v5 net-next 0/5] Allow TX forwarding for the software bridge
 data path to be offloaded to capable devices

Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Thu, 22 Jul 2021 18:55:37 +0300 you wrote:
> On RX, switchdev drivers have the ability to mark packets for the
> software bridge as "already forwarded in hardware" via
> skb->offload_fwd_mark. This instructs the nbp_switchdev_allowed_egress()
> function to perform software forwarding of that packet only to the bridge
> ports that are not in the same hardware domain as the source packet.
> 
> This series expands the concept for TX, in the sense that we can trust
> the accelerator to:
> (a) look up its FDB (which is more or less in sync with the software
>     bridge FDB) for selecting the destination ports for a packet
> (b) replicate the frame in hardware in case it's a multicast/broadcast,
>     instead of the software bridge having to clone it and send the
>     clones to each net device one at a time. This reduces the bandwidth
>     needed between the CPU and the accelerator, as well as the CPU time
>     spent.
> 
> [...]

Here is the summary with links:
  - [v5,net-next,1/5] net: bridge: switchdev: allow the TX data plane forwarding to be offloaded
    https://git.kernel.org/netdev/net-next/c/472111920f1c
  - [v5,net-next,2/5] net: dsa: track the number of switches in a tree
    https://git.kernel.org/netdev/net-next/c/5b22d3669f2f
  - [v5,net-next,3/5] net: dsa: add support for bridge TX forwarding offload
    https://git.kernel.org/netdev/net-next/c/123abc06e74f
  - [v5,net-next,4/5] net: dsa: mv88e6xxx: map virtual bridges with forwarding offload in the PVT
    https://git.kernel.org/netdev/net-next/c/ce5df6894a57
  - [v5,net-next,5/5] net: dsa: tag_dsa: offload the bridge forwarding process
    https://git.kernel.org/netdev/net-next/c/d82f8ab0d874

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html