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

patchwork-bot+netdevbpf at kernel.org patchwork-bot+netdevbpf at kernel.org
Fri Jul 23 15:50:05 UTC 2021


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
  - [v5,net-next,2/5] net: dsa: track the number of switches in a tree
  - [v5,net-next,3/5] net: dsa: add support for bridge TX forwarding offload
  - [v5,net-next,4/5] net: dsa: mv88e6xxx: map virtual bridges with forwarding offload in the PVT
  - [v5,net-next,5/5] net: dsa: tag_dsa: offload the bridge forwarding process

You are awesome, thank you!
Deet-doot-dot, I am a bot.

More information about the Bridge mailing list