Thread (21 messages) flat view 21 messages, 4 authors, 2026-02-06

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

From: Andrew Lunn <andrew@lunn.ch>
Date: 2026-02-06 17:17:36
Also in: linux-renesas-soc, lkml

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help