netdev - Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine

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: <38e09d91-c514-4090-8e31-1709073b237a@lunn.ch>
Date: Fri, 6 Feb 2026 16:55:30 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Nikita Yushchenko <nikita.yoush@...entembedded.com>
Cc: Michael Dege <michael.dege@...esas.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Christian Mardmoeller <christian.mardmoeller@...esas.com>,
	Dennis Ostermann <dennis.ostermann@...esas.com>
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload
 statemachine

On Fri, Feb 06, 2026 at 11:34:24AM +0100, Nikita Yushchenko wrote:
> > Unfortunately, your argumentation is very _academic_. There is _no_practical_reason_, not to
> > forward the traffic to the SW bridge via the HW bridge, even if only one link is currently up.
> 
> The very practical reason not to forward packet to SW when it can be handled
> in HW is - reduce SW load. SW cores have no chance to handle the load if you
> forward everything to SW at the channel speed.
> 
> The very thing I was trying to achieve when working on this offload support
> was - detect the case when a frame can be processed correctly in HW, and let
> it process it in HW, without notifying SW. And send frame to SW if and only
> if it is not possible to provide correct processing without that.
> 
> But this does not directly affect the case being discussed.
> 
> When there is only one port with enabled HW forwarding, there is no effect
> of keeping HW forwarding enabled, because the allowed destination mask
> computed nearby does not contain any destinations. Forwarding to CPU port
> was never handled via L2 forwarding (*), because L2 forwarding on rswitch
> requires explicit adding any possible destination MAC to the L2 table -

Are you saying this switch does not do address learning? In general,
or just not for the CPU port?

DSA switches handle the CPU port in a few different ways:

* They do address learning, so learn what MAC addresses are in the
  direction of the CPU from the traffic sent by the CPU.

* All frames with a destination MAC address not in the address
  translation unit get sent to the CPU. This is sometimes implicit,
  the CPU is included in the flood for unknown MAC addresses, or there
  is an explicit bit to enable this.  The software bridge will then
  handle the frame. The reply, if there is one, should then trigger
  address learning.

* The switch driver taps into the events the software bridge issues as
  it does address learning. This allows the switch to setup its
  address translation tables to mirror the software switch.

The overall result is that having just one switch port in the bridge
is no different to having multiple switch ports in the bridge.

	Andrew