[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 3 Mar 2022 15:35:29 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Alvin Šipraga <ALSI@...g-olufsen.dk>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
Ido Schimmel <idosch@...dia.com>,
Tobias Waldekranz <tobias@...dekranz.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
"UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH net-next 00/10] DSA unicast filtering
On Thu, Mar 03, 2022 at 03:13:41PM +0000, Alvin Šipraga wrote:
> So, yes, we do call .port_fdb_add() "on" the CPU port (i.e. the 'port'
> argument refers to the port number of the CPU port). But this just means
> telling the switch to forward packets with MAC DA 'addr' to 'port'. The
> actual forwarding database - (standalone) port, or bridge, or LAG
> database - is determined by the 'db' parameter. It is up to the DSA
> driver to make sense of the info in db.{dp,bridge,lag} in order to
> ensure proper FDB isolation, such that the entry is only matched (on
> packet ingress) by the ports implied by the given database (a single
> standalone port, or a group of ports belonging to the same bridge, or a
> group of ports in a LAG).
This is indeed what I was trying to say.
Powered by blists - more mailing lists