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:
 <TYRPR01MB14284CC099C09A99CFB31B66E8266A@TYRPR01MB14284.jpnprd01.prod.outlook.com>
Date: Fri, 6 Feb 2026 13:21:43 +0000
From: Michael Dege <michael.dege@...esas.com>
To: Nikita Yushchenko <nikita.yoush@...entembedded.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

Hello Nikita,

> -----Original Message-----
> From: Nikita Yushchenko <nikita.yoush@...entembedded.com>
> Sent: Friday, February 6, 2026 11:34 AM
> 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; linux-renesas-soc@...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. 

Well, we have heavily modified the driver in the past year. Now the MAC address of the GWCA (BR0) 
Is known to the HW MAC table and the packets destined for the GWCA are forwarded in HW. This works
quite well. At this pint there is still a problem with double broadcasting of packets with unknown
MAC address. I have a fix for that waiting to be reported. The next patch set will take care of this
and add VLAN support. We still have some experimenting to do to get the VLANs completely right for 
LLC packets. This should be ready within the next weeks.

> 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.

This has been superseded by the current driver version. And will be improved by adding the 
exception path for packets with unknown MAC addresses. The packets with unknown MAC address will
be port forwarded to Linux bridge device. It will the broadcast the packet and thereby both HW and
the SW bridge will learn the new MAC address.

> 
> (*) 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

Best regards,

Michael