[PATCH net] net: renesas: rswitch: fix forwarding offload statemachine

A change of the port state of one port, caused the state of another
port to change. This behvior was unintended.

Signed-off-by: Michael Dege <redacted>
---
A change of the port state of one port, caused the state of another
port to change. This behvior was unintended.

Fixes: b7502b1043de86967ff341819d05e09a8dbe8b2b ("net: renesas: rswitch: add offloading for L2 switching")
---
 drivers/net/ethernet/renesas/rswitch_l2.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/renesas/rswitch_l2.c b/drivers/net/ethernet/renesas/rswitch_l2.c
index 4a69ec77d69c..dcf726793bdc 100644
--- a/drivers/net/ethernet/renesas/rswitch_l2.c
+++ b/drivers/net/ethernet/renesas/rswitch_l2.c

@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Renesas Ethernet Switch device driver
  *
- * Copyright (C) 2025 Renesas Electronics Corporation
+ * Copyright (C) 2025 - 2026 Renesas Electronics Corporation
  */
 
 #include <linux/err.h>

@@ -88,7 +88,8 @@ static void rswitch_update_l2_hw_forwarding(struct rswitch_private *priv)
 		    rdev->forwarding_requested &&
 		    !rdev->forwarding_offloaded) {
 			rswitch_change_l2_hw_offloading(rdev, true, false);
-		} else if (rdev->forwarding_offloaded) {
+		} else if (rdev->forwarding_offloaded &&
+			   !rdev->forwarding_requested) {
 			rswitch_change_l2_hw_offloading(rdev, false, false);
 		}
 	}

---
base-commit: f14faaf3a1fb3b9e4cf2e56269711fb85fba9458
change-id: 20260205-fix-offloading-statemachine-1d301630a08d

Best regards,
-- 
Michael Dege [off-list ref]

Hello Michael

Although indeed the condition in the current code is not correct, I'm not sure comfortable with this fix.

Full condition for a port to be a valid candidate for hardware forwarding is

  rdev_for_l2_offload() && rdev->forwarding_requested

It is not obvious if at this point rdev_for_l2_offload() could get changed from the last call to rswitch_change_l2_hw_offloading(), so using only the partial condition at this point does not look good for me.

I'd suggest to either change to something like

if (rdev_for_l2_offload() && rdev->forwarding_requested && !rdev->forwarding_offloaded)
	rswitch_change_l2_hw_offloading(rdev, true, false);
if (!(rdev_for_l2_offload() && rdev->forwarding_requested) && rdev->forwarding_offloaded)
	rswitch_change_l2_hw_offloading(rdev, false, false);

Or maybe just

if (rdev_for_l2_offload() && rdev->forwarding_requested)
	rswitch_change_l2_hw_offloading(rdev, true, false);
else
	rswitch_change_l2_hw_offloading(rdev, false, false);

since rswitch_change_l2_hw_offloading() has internal check for the current state and returns early if the requested change is already applied.

Nikita

   rdev_for_l2_offload() && rdev->forwarding_requested

rdev_for_l2_offload(rdev) && rdev->forwarding_requested

Hello Nikita,

-----Original Message-----
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Sent: Thursday, February 5, 2026 8:47 AM
To: Michael Dege <redacted>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
Andrew Lunn [off-list ref]; David S. Miller [off-list ref]; Eric Dumazet
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni [off-list ref]
Cc: <redacted>; <redacted>; <redacted>
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine

Hello Michael

quoted

-		} else if (rdev->forwarding_offloaded) {
+		} else if (rdev->forwarding_offloaded &&
+			   !rdev->forwarding_requested) {
  			rswitch_change_l2_hw_offloading(rdev, false, false);
  		}

Although indeed the condition in the current code is not correct, I'm not sure comfortable with this
fix.

Full condition for a port to be a valid candidate for hardware forwarding is

   rdev_for_l2_offload() && rdev->forwarding_requested

It is not obvious if at this point rdev_for_l2_offload() could get changed from the last call to
rswitch_change_l2_hw_offloading(), so using only the partial condition at this point does not look
good for me.

I'd suggest to either change to something like

if (rdev_for_l2_offload() && rdev->forwarding_requested && !rdev->forwarding_offloaded)
	rswitch_change_l2_hw_offloading(rdev, true, false); if (!(rdev_for_l2_offload() && rdev-

quoted

forwarding_requested) && rdev->forwarding_offloaded)

	rswitch_change_l2_hw_offloading(rdev, false, false);

Or maybe just

if (rdev_for_l2_offload() && rdev->forwarding_requested)
	rswitch_change_l2_hw_offloading(rdev, true, false); else
	rswitch_change_l2_hw_offloading(rdev, false, false);

5 more quoted lines

Thank you for your comment.

Let me study and test your suggestion.

Best regards,

Michael

WBR,
Nikita Yushchenko,
System Software Engineer @ Cogent Embedded

05.02.2026 08:47, Nikita Yushchenko wrote:

Hello Michael

quoted

-        } else if (rdev->forwarding_offloaded) {
+        } else if (rdev->forwarding_offloaded &&
+               !rdev->forwarding_requested) {
              rswitch_change_l2_hw_offloading(rdev, false, false);
          }

Although indeed the condition in the current code is not correct, I'm not sure comfortable with this fix.

Full condition for a port to be a valid candidate for hardware forwarding is

   rdev_for_l2_offload() && rdev->forwarding_requested

It is not obvious if at this point rdev_for_l2_offload() could get changed from the last call to rswitch_change_l2_hw_offloading(), so using only the partial condition at this point does not look good for me.

I'd suggest to either change to something like

if (rdev_for_l2_offload() && rdev->forwarding_requested && !rdev->forwarding_offloaded)
     rswitch_change_l2_hw_offloading(rdev, true, false);
if (!(rdev_for_l2_offload() && rdev->forwarding_requested) && rdev->forwarding_offloaded)
     rswitch_change_l2_hw_offloading(rdev, false, false);

Or maybe just

if (rdev_for_l2_offload() && rdev->forwarding_requested)
     rswitch_change_l2_hw_offloading(rdev, true, false);
else
     rswitch_change_l2_hw_offloading(rdev, false, false);

since rswitch_change_l2_hw_offloading() has internal check for the current state and returns early if the requested change is already applied.

May be even better to add

  bool new_forwarding_offloaded = rdev_for_l2_offload(rdev) && rdev->forwarding_requested;

at the beginning of the loop body, and use this flag over the loop - it will make the code shorter and cleaner.

Hello Nikita,

Thank you once more for your comments.

-----Original Message-----
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Sent: Thursday, February 5, 2026 8:59 AM
To: Michael Dege <redacted>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
Andrew Lunn [off-list ref]; David S. Miller [off-list ref]; Eric Dumazet
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni [off-list ref]
Cc: <redacted>; <redacted>; <redacted>
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine



WBR,
Nikita Yushchenko,
System Software Engineer @ Cogent Embedded

05.02.2026 08:47, Nikita Yushchenko wrote:

quoted

Hello Michael

quoted

-        } else if (rdev->forwarding_offloaded) {
+        } else if (rdev->forwarding_offloaded &&
+               !rdev->forwarding_requested) {
              rswitch_change_l2_hw_offloading(rdev, false, false);
          }

Although indeed the condition in the current code is not correct, I'm not sure comfortable with this

fix.

quoted

Full condition for a port to be a valid candidate for hardware
forwarding is

   rdev_for_l2_offload() && rdev->forwarding_requested

It is not obvious if at this point rdev_for_l2_offload() could get
changed from the last call to rswitch_change_l2_hw_offloading(), so
using only the partial condition at this point does not look good for me.

I'd suggest to either change to something like

if (rdev_for_l2_offload() && rdev->forwarding_requested &&
!rdev->forwarding_offloaded)

4 more quoted lines

This works as expected.

quoted

Or maybe just

if (rdev_for_l2_offload() && rdev->forwarding_requested)
     rswitch_change_l2_hw_offloading(rdev, true, false); else
     rswitch_change_l2_hw_offloading(rdev, false, false);

since rswitch_change_l2_hw_offloading() has internal check for the
current state and returns early if the requested change is already applied.

Unfortunately, this has a side effect, e.g., if you pull the cable on tsn0 and the link 
goes down, you will see that the offloading is disabled on all ports connected to the 
bridge and not just on tsn0.

May be even better to add

   bool new_forwarding_offloaded = rdev_for_l2_offload(rdev) && rdev->forwarding_requested;

at the beginning of the loop body, and use this flag over the loop - it will make the code shorter and
cleaner.

Yes, this does make the code cleaner. 

I will send around the updated patch shortly.

Best regards,

Michael

quoted

quoted

if (rdev_for_l2_offload() && rdev->forwarding_requested)
      rswitch_change_l2_hw_offloading(rdev, true, false); else
      rswitch_change_l2_hw_offloading(rdev, false, false);

since rswitch_change_l2_hw_offloading() has internal check for the
current state and returns early if the requested change is already applied.

Unfortunately, this has a side effect, e.g., if you pull the cable on tsn0 and the link
goes down, you will see that the offloading is disabled on all ports connected to the
bridge and not just on tsn0.

Quite strange, is anything else logged?  E.g. some messages from linux bridge layer?

Nikita

Hello Nikita,

-----Original Message-----
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Sent: Thursday, February 5, 2026 2:39 PM
To: Michael Dege <redacted>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
Andrew Lunn [off-list ref]; David S. Miller [off-list ref]; Eric Dumazet
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni [off-list ref]
Cc: <redacted>; <redacted>; <redacted>
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine

quoted

quoted

quoted

if (rdev_for_l2_offload() && rdev->forwarding_requested)
      rswitch_change_l2_hw_offloading(rdev, true, false); else
      rswitch_change_l2_hw_offloading(rdev, false, false);

since rswitch_change_l2_hw_offloading() has internal check for the
current state and returns early if the requested change is already applied.

Unfortunately, this has a side effect, e.g., if you pull the cable on
tsn0 and the link goes down, you will see that the offloading is
disabled on all ports connected to the bridge and not just on tsn0.

Quite strange, is anything else logged?  E.g. some messages from linux bridge layer?

Nikita

Here is the log from the version without "if else"

[   83.107759] renesas_eth_sw e6880000.ethernet tsn0: Link is Down
[   83.108734] br0: port 1(tsn0) entered disabled state
[   83.109669] renesas_eth_sw e6880000.ethernet tsn0: stopping hw learning
[   83.110519] renesas_eth_sw e6880000.ethernet tsn0: stopping hw forwarding
[   83.111405] renesas_eth_sw e6880000.ethernet tsn1: stopping hw forwarding
[   91.299976] renesas_eth_sw e6880000.ethernet tsn0: Link is Up - 1Gbps/Full - flow control off
[   91.357634] br0: port 1(tsn0) entered blocking state
[   91.358309] br0: port 1(tsn0) entered forwarding state
[   91.359185] renesas_eth_sw e6880000.ethernet tsn1: starting hw forwarding
[   91.360104] renesas_eth_sw e6880000.ethernet tsn0: starting hw learning
[   91.360943] renesas_eth_sw e6880000.ethernet tsn0: starting hw forwarding
[   91.361802] renesas_eth_sw e6880000.ethernet tsn1: stopping hw forwarding

And this is what it should look like:

[   81.027632] renesas_eth_sw e6880000.ethernet tsn0: Link is Down
[   81.028662] br0: port 1(tsn0) entered disabled state
[   81.029582] renesas_eth_sw e6880000.ethernet tsn0: stopping hw learning
[   81.030431] renesas_eth_sw e6880000.ethernet tsn0: stopping hw forwarding
[   90.243832] renesas_eth_sw e6880000.ethernet tsn0: Link is Up - 1Gbps/Full - flow control off
[   90.305291] br0: port 1(tsn0) entered blocking state
[   90.305956] br0: port 1(tsn0) entered forwarding state
[   90.306838] renesas_eth_sw e6880000.ethernet tsn0: starting hw learning
[   90.307725] renesas_eth_sw e6880000.ethernet tsn0: starting hw forwarding

Best regards

Michael

quoted

Quite strange, is anything else logged?  E.g. some messages from linux bridge layer?

Nikita

Here is the log from the version without "if else"

[   83.107759] renesas_eth_sw e6880000.ethernet tsn0: Link is Down
[   83.108734] br0: port 1(tsn0) entered disabled state
[   83.109669] renesas_eth_sw e6880000.ethernet tsn0: stopping hw learning
[   83.110519] renesas_eth_sw e6880000.ethernet tsn0: stopping hw forwarding
[   83.111405] renesas_eth_sw e6880000.ethernet tsn1: stopping hw forwarding

The driver was originally designed to enable hardware forwarding when not less than two ports are in forwarding state. When only one port has hw forwarding, there is no destination to forward.

Nikita

Hello Nikita,

-----Original Message-----
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Sent: Thursday, February 5, 2026 2:57 PM
To: Michael Dege <redacted>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
Andrew Lunn [off-list ref]; David S. Miller [off-list ref]; Eric Dumazet
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni [off-list ref]
Cc: <redacted>; <redacted>; <redacted>
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine

quoted

quoted

Quite strange, is anything else logged?  E.g. some messages from linux bridge layer?

Nikita

Here is the log from the version without "if else"

[   83.107759] renesas_eth_sw e6880000.ethernet tsn0: Link is Down
[   83.108734] br0: port 1(tsn0) entered disabled state
[   83.109669] renesas_eth_sw e6880000.ethernet tsn0: stopping hw learning
[   83.110519] renesas_eth_sw e6880000.ethernet tsn0: stopping hw forwarding
[   83.111405] renesas_eth_sw e6880000.ethernet tsn1: stopping hw forwarding

The driver was originally designed to enable hardware forwarding when not less than two ports are in
forwarding state. When only one port has hw forwarding, there is no destination to forward.

Nikita

The current driver allows Linux to use the bridge port as local port to the bridge. The offloading 
Also supports switching traffic to Linux through the bridge port. Therefore, the offloading shouldn't 
Be dropped if only one external port is up on the bridge.

Best regards,

Michael

quoted

The driver was originally designed to enable hardware forwarding when not less than two ports are in
forwarding state. When only one port has hw forwarding, there is no destination to forward.

Nikita

The current driver allows Linux to use the bridge port as local port to the bridge. The offloading
Also supports switching traffic to Linux through the bridge port. Therefore, the offloading shouldn't
Be dropped if only one external port is up on the bridge.

"Offloading" means - forward a frame from one hw port to other hw port without inserting it into CPU queue. Offloaded frame is never visible to software bridge.

There is code that allows offload only if the linux bridge device used to connect rswitch ports does not have anything else.  If it has something else, offloading is disabled (because there is no way to know when a frame can be processed within rswitch hw without sending it to cpu).

Nikita

WBR,
Nikita Yushchenko,
System Software Engineer @ Cogent Embedded

05.02.2026 15:41, Nikita Yushchenko wrote:

quoted

quoted

The driver was originally designed to enable hardware forwarding when not less than two ports are in
forwarding state. When only one port has hw forwarding, there is no destination to forward.

Nikita

The current driver allows Linux to use the bridge port as local port to the bridge. The offloading
Also supports switching traffic to Linux through the bridge port. Therefore, the offloading shouldn't
Be dropped if only one external port is up on the bridge.

"Offloading" means - forward a frame from one hw port to other hw port without inserting it into CPU queue. Offloaded frame is never visible to software bridge.

There is code that allows offload only if the linux bridge device used to connect rswitch ports does not have anything else.  If it has something else, offloading is disabled (because there is no way to know when a frame can be processed within rswitch hw without sending it to cpu).

A frame being received by bridge device itself is not a subject for offload, ever.

quoted

quoted

The driver was originally designed to enable hardware forwarding when not less than two ports are in
forwarding state. When only one port has hw forwarding, there is no destination to forward.

Nikita

The current driver allows Linux to use the bridge port as local port to the bridge. The offloading
Also supports switching traffic to Linux through the bridge port. Therefore, the offloading shouldn't
Be dropped if only one external port is up on the bridge.

"Offloading" means - forward a frame from one hw port to other hw port without inserting it into CPU queue. Offloaded frame is never visible to software bridge.

There is code that allows offload only if the linux bridge device used to connect rswitch ports does not have anything else.  If it has something else, offloading is disabled (because there is no way to know when a frame can be processed within rswitch hw without sending it to cpu).

Ah I see the code that explicitly enabled l2 offload only when at least two ports are active is not in mainline.

Still, l2 offload requires at least two ports participating, by definition.
When there is only one port with hw forwarding enabled, it will get empty allowed forward destination mask.

Hello Nikita,

-----Original Message-----
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Sent: Thursday, February 5, 2026 3:45 PM
To: Michael Dege <redacted>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
Andrew Lunn [off-list ref]; David S. Miller [off-list ref]; Eric Dumazet
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni [off-list ref]
Cc: <redacted>; <redacted>; <redacted>
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine



WBR,
Nikita Yushchenko,
System Software Engineer @ Cogent Embedded

05.02.2026 15:41, Nikita Yushchenko wrote:

quoted

quoted

quoted

The driver was originally designed to enable hardware forwarding
when not less than two ports are in forwarding state. When only one port has hw forwarding, there

is no destination to forward.

quoted

quoted

quoted

Nikita

The current driver allows Linux to use the bridge port as local port
to the bridge. The offloading Also supports switching traffic to
Linux through the bridge port. Therefore, the offloading shouldn't Be dropped if only one external

port is up on the bridge.

quoted

"Offloading" means - forward a frame from one hw port to other hw port
without inserting it into CPU queue. Offloaded frame is never visible to software bridge.

There is code that allows offload only if the linux bridge device used
to connect rswitch ports does not have anything else.  If it has
something else, offloading is disabled (because there is no way to know when a frame can be

processed within rswitch hw without sending it to cpu).

A frame being received by bridge device itself is not a subject for offload, ever.

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. 
Your suggestion to switch to port forwarding if only one external link is up, makes the 
overall HW switch handling overly complicated. Especially when VLANs come into the picture 
and this patch is leading towards the introduction of VLANs.

If you look at the behavior of the SW bridge, it does not change its operating state even if 
all links but one go down. So why should we go through the hassle to _temporarily_ switch the 
remaining port to port forwarding?

Another feature, "exception path for MAC learning", which will be coming for the VLAN 
Introduction probably makes the is whole offloading and learning handling obsolete. Then we 
can just set the forwarding rule in the HW bridge once a port is added to the bridge.

Best regards,

Michael

Hello Nikita,

I am sorry I missed this latest message of yours.

-----Original Message-----
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Sent: Thursday, February 5, 2026 4:04 PM
To: Michael Dege <redacted>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
Andrew Lunn [off-list ref]; David S. Miller [off-list ref]; Eric Dumazet
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni [off-list ref]
Cc: <redacted>; <redacted>; <redacted>
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine

quoted

quoted

quoted

The driver was originally designed to enable hardware forwarding
when not less than two ports are in forwarding state. When only one port has hw forwarding, there

is no destination to forward.

quoted

quoted

quoted

Nikita

The current driver allows Linux to use the bridge port as local port
to the bridge. The offloading Also supports switching traffic to
Linux through the bridge port. Therefore, the offloading shouldn't Be dropped if only one external

port is up on the bridge.

quoted

"Offloading" means - forward a frame from one hw port to other hw port
without inserting it into CPU queue. Offloaded frame is never visible to software bridge.

There is code that allows offload only if the linux bridge device used
to connect rswitch ports does not have anything else.  If it has
something else, offloading is disabled (because there is no way to know when a frame can be

processed within rswitch hw without sending it to cpu).

Ah I see the code that explicitly enabled l2 offload only when at least two ports are active is not in
mainline.

Still, l2 offload requires at least two ports participating, by definition.
When there is only one port with hw forwarding enabled, it will get empty allowed forward destination
mask.

Yes, that is right, but there are still two HW ports involved in the HW forwarding. The remaining TSN 
port and the GWCA as internal port. Therefore, it is OK from the HW viewpoint.

Best regards,

Michael

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

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

Hello Nikita,

-----Original Message-----
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Sent: Friday, February 6, 2026 11:34 AM
To: Michael Dege <redacted>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
Andrew Lunn [off-list ref]; David S. Miller [off-list ref]; Eric Dumazet
[off-list ref]; Jakub Kicinski [off-list ref]; Paolo Abeni [off-list ref]
Cc: <redacted>; <redacted>; <redacted>; Christian
Mardmoeller [off-list ref]; Dennis Ostermann [off-list ref]
Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine

quoted

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

On Fri, Feb 06, 2026 at 11:34:24AM +0100, Nikita Yushchenko wrote:

quoted

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

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.

rswitch does not support hardware learning on CPU port.

To make use of L2 forwarding to CPU port, one has to add destinations to MAC table manually.

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

rswitch does not do anything implicitly, each frame is processed by trying in order:
- match it against "streams" in L3 table,
- match it against destination addresses in L2 table,
- match it against VLAN table (VLAN id only),
- try port-based forwarding (i.e. common rule for anything coming from particular ingress port)

At each of this level, it is possible to configure one or several destinations to forward frame to.
Flooding can be implemented e.g. by configuring "port based" for each port to forward to all other ports, so if a frame is matched at earlier stages then it is processed per what is defined there, and if not then it is flooded.

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

For rswitch there is no easy way to sync hardware-learned L2 entries to software.
There are no notifications of hardware updates.

Options are:
- either periodically scan hardware table, or
- disable hardware learning at all and send any unknown frames to software bridge, so it learns, and then handle notifications about that and manually update hardware table.

The existing implementation does not try to sync sw and hw tables at all.

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

In my original driver, I enabled L2 forwarding only when at least two ports have been participating.
I don't see rationale for doing differently on this hardware.
But Renesas can have a different view on this.

Nikita

On Fri, Feb 06, 2026 at 05:10:26PM +0100, Nikita Yushchenko wrote:

quoted

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.

rswitch does not support hardware learning on CPU port.

To make use of L2 forwarding to CPU port, one has to add destinations to MAC table manually.

O.K. That helps explain a few things.

quoted

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

rswitch does not do anything implicitly, each frame is processed by trying in order:
- match it against "streams" in L3 table,
- match it against destination addresses in L2 table,
- match it against VLAN table (VLAN id only),
- try port-based forwarding (i.e. common rule for anything coming from particular ingress port)

At each of this level, it is possible to configure one or several destinations to forward frame to.
Flooding can be implemented e.g. by configuring "port based" for each port
to forward to all other ports, so if a frame is matched at earlier stages
then it is processed per what is defined there, and if not then it is
flooded.

So it sounds like you could flood to the CPU port?

quoted

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

For rswitch there is no easy way to sync hardware-learned L2 entries to software.
There are no notifications of hardware updates.

I was meaning the other way around. The software L2 entries can be
placed into the switch, to make up for the switches inability to
perform learning on the CPU port.

If you flood unknown destinations to the CPU, the CPU will do address
learning. The software bridge will flood the frame to its other ports,
and when there is a reply, it will add an entry to its table. You can
then mirror that to the hardware, so you gain address learning on the
CPU port.

In my original driver, I enabled L2 forwarding only when at least two ports have been participating.
I don't see rationale for doing differently on this hardware.
But Renesas can have a different view on this.

So there argument is that it simplifies the code. We might want to see
the patchset, see how much code they manage to delete.

    Andrew