linux-kernel - 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: <1aa615e2-1297-40a9-b7c4-beb943996721@cogentembedded.com>
Date: Fri, 6 Feb 2026 11:34:24 +0100
From: Nikita Yushchenko <nikita.yoush@...entembedded.com>
To: 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>
Cc: "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

> 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 - which is problematic for CPU 
port, in generic case your software bridge device can be a part of a higher level construct, and you 
will have hard times to dynamically catch and process any changes in the list of possible destination 
MACs for the CPU port. For exact this reason, I implemented forwarding to SW port using "port based" 
thing, that is actually a fallback that rswitch uses when L3/L2 forwarding fails due to no table match.

(*) when virtual ports come into scope, a case for L2 forwarding to CPU port appears.  But still, 
"default" forwarding to SW is never handled as L2 forwarding.

Nikita