[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220210153053.53jwxh2ggtbccxo2@skbuf>
Date: Thu, 10 Feb 2022 15:30:54 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: 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>,
Roopa Prabhu <roopa@...dia.com>,
Nikolay Aleksandrov <nikolay@...dia.com>,
Jiri Pirko <jiri@...dia.com>, Ido Schimmel <idosch@...dia.com>,
Rafael Richter <rafael.richter@....de>,
Daniel Klauer <daniel.klauer@....de>,
Tobias Waldekranz <tobias@...dekranz.com>
Subject: Re: [RFC PATCH net-next 5/5] net: dsa: add explicit support for host
bridge VLANs
On Wed, Feb 09, 2022 at 11:30:43PM +0200, Vladimir Oltean wrote:
> - It is possible to artificially fill the VLAN table of a switch, by
> walking through the entire VLAN space, adding and deleting them.
> For each VLAN added on a user port, DSA will add it on shared ports
> too, but for each VLAN deletion on a user port, it will remain
> installed on shared ports, since DSA has no good indication of whether
> the VLAN is still in use or not. If the hardware has a limited number
> of VLAN table entries, this may uselessly consume that space.
There's another, more important angle to this which I forgot while I was
writing the commit message. If you don't have a way to delete VLANs on
CPU ports, you have no way of removing yourself from a VLAN with noisy
stations, once you've entered it. I'll make sure to update the commit
message for v2.
Powered by blists - more mailing lists