[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171106232627.GB22474@lunn.ch>
Date: Tue, 7 Nov 2017 00:26:27 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Subject: Re: [PATCH] net: dsa: Don't add vlans when vlan filtering is disabled
On Mon, Nov 06, 2017 at 03:13:19PM -0800, Florian Fainelli wrote:
> Hi Andrew,
>
> On 11/06/2017 03:04 PM, Andrew Lunn wrote:
> > The software bridge can be build with vlan filtering support
> > included. However, by default it is turned off. In its turned off
> > state, it still passes VLANs via switchev, even though they are not to
> > be used. Don't pass these VLANs to the hardware. Only do so when vlan
> > filtering is enabled.
>
> Do not we have a possible interface problem here in that we should know
> whether VLAN filtering is enabled or not, and in such a case switch
> drivers should do the following:
>
> - if VLAN filtering is disabled, accept VLAN programming coming from
> DSA, but do not enforce that frames ingress/egressing with an unknown
> VID be rejected
Hi Florian
We know if vlan filtering is enabled or not, via two different
mechanism. br_vlan_enabled() tells us this, and we can call it
anytime. There is also a switchdev call when the state changes.
If vlan filtering is disabled, we allow all vlans through. Hence there
should not be any need to tell the hardware about the VLANs. It should
be passing them all anyway. If filtering is enabled, then clearly we
do have to program the hardware with the vlans.
> - if VLAN filtering is enabled, accept VLAN programming coming from DSA,
> enforce that frames ingressing/egressing with an unknown VID should be
> rejected
That is todays behaviour, and is unchanged.
Andrew
Powered by blists - more mailing lists