[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201029000531.GD933237@lunn.ch>
Date: Thu, 29 Oct 2020 01:05:31 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Kurt Kanzenbach <kurt@...utronix.de>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
ilias.apalodimas@...aro.org,
Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net-next v7 2/8] net: dsa: Give drivers the chance to
veto certain upper devices
On Wed, Oct 28, 2020 at 12:43:44PM +0200, Vladimir Oltean wrote:
> On Wed, Oct 28, 2020 at 08:42:15AM +0100, Kurt Kanzenbach wrote:
> > From: Vladimir Oltean <vladimir.oltean@....com>
> >
> > Some switches rely on unique pvids to ensure port separation in
> > standalone mode, because they don't have a port forwarding matrix
> > configurable in hardware. So, setups like a group of 2 uppers with the
> > same VLAN, swp0.100 and swp1.100, will cause traffic tagged with VLAN
> > 100 to be autonomously forwarded between these switch ports, in spite
> > of there being no bridge between swp0 and swp1.
> >
> > These drivers need to prevent this from happening. They need to have
> > VLAN filtering enabled in standalone mode (so they'll drop frames tagged
> > with unknown VLANs) and they can only accept an 8021q upper on a port as
> > long as it isn't installed on any other port too. So give them the
> > chance to veto bad user requests.
> >
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> > Signed-off-by: Kurt Kanzenbach <kurt@...utronix.de>
> > ---
>
> In case reviewers have doubts about this new DSA operation in general.
> I would expect that when LAG support is merged, some drivers will
> support it, but not any tx_type, but e.g. just NETDEV_LAG_TX_TYPE_HASH.
> So it would also be helpful in that case, so they could veto other types
> of bond interfaces cleanly. So I do see the need for a generic
> "prechangeupper" operation given to drivers.
There is always the interesting question, do we want to veto, or
simply not accelerate it? We will want to consider that case by case.
Andrew
Powered by blists - more mailing lists