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

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

[Michael Dege]

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 <michael.dege@renesas.com>
---
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 <michael.dege@renesas.com>

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

[Nikita Yushchenko]

Hello Michael

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

Nikita

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

[Nikita Yushchenko]

>    rdev_for_l2_offload() && rdev->forwarding_requested

rdev_for_l2_offload(rdev) && rdev->forwarding_requested

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

[Michael Dege]

Hello Nikita,

> -----Original Message-----
> From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Sent: Thursday, February 5, 2026 8:47 AM
> To: Michael Dege <michael.dege@renesas.com>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> Cc: netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine
> 
> Hello Michael
> 
> > -		} 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.
> 
> Nikita

Thank you for your comment.

Let me study and test your suggestion.

Best regards,

Michael

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

[Nikita Yushchenko]

WBR,
Nikita Yushchenko,
System Software Engineer @ Cogent Embedded

05.02.2026 08:47, Nikita Yushchenko wrote:
> Hello Michael
> 
>> -        } 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.

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

[Michael Dege]

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 <michael.dege@renesas.com>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> Cc: netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-kernel@vger.kernel.org
> 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:
> > Hello Michael
> >
> >> -        } 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);

This works as expected.

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

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

[Nikita Yushchenko]

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

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

[Michael Dege]

Hello Nikita,

> -----Original Message-----
> From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Sent: Thursday, February 5, 2026 2:39 PM
> To: Michael Dege <michael.dege@renesas.com>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> Cc: netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine
> 
> >>> 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

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

[Nikita Yushchenko]

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

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

[Michael Dege]

Hello Nikita,


> -----Original Message-----
> From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Sent: Thursday, February 5, 2026 2:57 PM
> To: Michael Dege <michael.dege@renesas.com>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> Cc: netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine
> 
> >> 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

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

[Nikita Yushchenko]

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

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

[Nikita Yushchenko]

WBR,
Nikita Yushchenko,
System Software Engineer @ Cogent Embedded

05.02.2026 15:41, Nikita Yushchenko wrote:
>>> 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.

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

[Nikita Yushchenko]

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

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

[Michael Dege]

Hello Nikita,

> -----Original Message-----
> From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Sent: Thursday, February 5, 2026 3:45 PM
> To: Michael Dege <michael.dege@renesas.com>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> Cc: netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-kernel@vger.kernel.org
> 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:
> >>> 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.

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

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

[Michael Dege]

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 <michael.dege@renesas.com>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> Cc: netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine
> 
> >>> 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.

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

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

[Nikita Yushchenko]

> 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

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

[Nikita Yushchenko]

> 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

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

[Michael Dege]

Hello Nikita,

> -----Original Message-----
> From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> Sent: Friday, February 6, 2026 11:34 AM
> To: Michael Dege <michael.dege@renesas.com>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>;
> Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> Cc: netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-kernel@vger.kernel.org; Christian
> Mardmoeller <christian.mardmoeller@renesas.com>; Dennis Ostermann <dennis.ostermann@renesas.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

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

[Andrew Lunn]

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

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

[Nikita Yushchenko]

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

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

[Andrew Lunn]

On Fri, Feb 06, 2026 at 05:10:26PM +0100, Nikita Yushchenko wrote:
> > 
> > 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.

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

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