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: <da7edbbd-5a31-46a3-a091-b06ca4fee683@cogentembedded.com>
Date: Fri, 6 Feb 2026 17:10:26 +0100
From: Nikita Yushchenko <nikita.yoush@...entembedded.com>
To: Andrew Lunn <andrew@...n.ch>
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

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