From: Ido Schimmel <idosch@idosch•org>
To: Vivien Didelot <vivien.didelot@savoirfairelinux•com>
Cc: Andrew Lunn <andrew@lunn•ch>,
Toshiaki Makita <toshiaki.makita1@gmail•com>,
Toshiaki Makita <makita.toshiaki@lab•ntt.co.jp>,
David Miller <davem@davemloft•net>,
netdev <netdev@vger•kernel.org>
Subject: Re: [PATCH net] net: br: Fix igmp snooping offload with CONFIG_BRIDGE_VLAN_FILTERING
Date: Tue, 3 Oct 2017 19:42:11 +0300 [thread overview]
Message-ID: <20171003164211.GA5177@shredder.mtl.com> (raw)
In-Reply-To: <87infwtd0b.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On Tue, Oct 03, 2017 at 12:25:08PM -0400, Vivien Didelot wrote:
> Andrew Lunn <andrew@lunn•ch> writes:
>
> >> The vlan will be effective only when vlan_filtering is enabled.
> >> When vlan_filtering is disabled, vlan information is still kept in the
> >> bridge and gets effective later when vlan_filtering becomes enable.
> >
> > O.K, so things are starting to get clearer.
> >
> > So when vlan filtering is disabled, the hardware should just ignore
> > the requests to add the vlan to the hardware?
> >
> > When vlan_filtering is enabled, are all the vlans in the software
> > bridge again offloaded? Or do we need to remember all the vlans which
> > we ignored while vlan filtering was disabled? The average switch has
> > nowhere to store these disabled vlans. It can only store active vlans.
>
> When vlan_filtering is enabled on the bridge, the bridge code does
> propagates the default_pvid again if I recall correctly.
>
> In my opinion the hardware mustn't ignore the VLAN requests, because we
> seem to agree that vlan_filtering disabled means that the target ports
> should not care yet about 802.1Q. So having some unused hardware VLAN
> entries and some ports with disabled 802.1Q mode must work together.
>
> That being said we still have the wrong hardware FDB populated when
> CONFIG_BRIDGE_VLAN_FILTERING is enabled but not vlan_filtering...
The driver can make sure it's able to handle the configured
`vlan_filtering` state during port enslavement to the bridge and also
forbid it from being toggled once it's enslaved.
next prev parent reply other threads:[~2017-10-03 16:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-03 0:55 [PATCH net] net: br: Fix igmp snooping offload with CONFIG_BRIDGE_VLAN_FILTERING Andrew Lunn
2017-10-03 3:29 ` Toshiaki Makita
2017-10-03 12:16 ` Andrew Lunn
2017-10-03 14:57 ` Vivien Didelot
2017-10-03 15:03 ` Toshiaki Makita
2017-10-03 15:30 ` Andrew Lunn
2017-10-03 16:25 ` Vivien Didelot
2017-10-03 16:42 ` Ido Schimmel [this message]
2017-10-04 4:52 ` Toshiaki Makita
2017-10-04 12:31 ` Ido Schimmel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171003164211.GA5177@shredder.mtl.com \
--to=idosch@idosch$(echo .)org \
--cc=andrew@lunn$(echo .)ch \
--cc=davem@davemloft$(echo .)net \
--cc=makita.toshiaki@lab$(echo .)ntt.co.jp \
--cc=netdev@vger$(echo .)kernel.org \
--cc=toshiaki.makita1@gmail$(echo .)com \
--cc=vivien.didelot@savoirfairelinux$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox