[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <59c7e214-8fbe-42bb-9da0-df41b1794d37@lunn.ch>
Date: Fri, 6 Feb 2026 18:17:26 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Nikita Yushchenko <nikita.yoush@...entembedded.com>
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
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
Powered by blists - more mailing lists