RE: [EXT] Re: [PATCH v6 3/3] net: dsa: ocelot: Add support for QinQ Operation
Hi Vladimir, > > I asked this on the Microchip Support portal: > > -[cut here]- > > VLAN filtering only on specific TPID > > > I would like to configure a port with the following behavior: > - The VLAN table should contain 802.1ad VLANs 1 and 10. VLAN ingress > filtering > should be enabled. > - An untagged frame on ingress should be classified to 802.1ad (TAG_TYPE=1) > VLAN ID 1 (the port-based VLAN). The frame should be accepted because > 802.1ad > VLAN 1 is in the VLAN table. > - An ingress frame with 802.1Q (0x8100) header VLAN ID 100 should be > classified > to 802.1ad (TAG_TYPE=1) VLAN ID 1 (the port-based VLAN). The frame > should be > accepted because 802.1ad VLAN 1 is in the VLAN table. > - An ingress frame with 802.1ad (0x88a8) header VLAN ID 10 should be > classified > to 802.1ad (TAG_TYPE=1) VLAN ID 10. The frame should be accepted > because > 802.1ad VLAN 10 is in the VLAN table. > - An ingress frame with 802.1ad (0x88a8) header VLAN ID 100 should be > classified to 802.1ad (TAG_TYPE=1) VLAN ID 100. The frame should be > dropped > because 802.1ad VLAN 100 is not in the VLAN table. > How do I configure the switch to obtain this behavior? This is not what the > "Provider Bridges and Q-in-Q Operation" chapter in the reference manual is > explaining how to do. Instead, that chapter suggests to make > VLAN_CFG.VLAN_AWARE_ENA = 0. But I don't want to do this, because I need > to be able to drop the frames with 802.1ad VLAN ID 100 in the example above. > > -[cut here]- > > Judging from the fact that I received no answer whatsoever, I can only deduce > that offloading an 8021ad bridge, at least one that has the semantics that > Toshiaki Makita described here, > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern > el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnetdev%2Fnet-next.git%2F > commit%2F%3Fid%3D1a0b20b257326523ec2a6cb51dd6f26ef179eb84 > data=02%7C01%7Chongbo.wang%40nxp.com%7Cdcfd5e5df4e24455726408d > 86c4f0493%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6373784 > 33917654330sdata=kk8WnA0iH9E5yPrLKC8BwSInD6jqm0qGftJ8Jw1Etk > 8%3Dreserved=0 > is not possible with this hardware. > > So I think there's little left to do here. > > If it helps, I am fairly certain that the sja1105 can offer the requested > services, > if you play a little bit with the TPID and TPID2 values. Maybe that's a path > forward for your patches, if you still want to add the generic support in > switchdev and in DSA. > Thanks for your suggestion, I will research the related code, and will optimize my patches. Thanks, hongbo
Re: [EXT] Re: [PATCH v6 3/3] net: dsa: ocelot: Add support for QinQ Operation
Hi Hongbo, On Thu, Sep 17, 2020 at 02:37:59AM +, Hongbo Wang wrote: > > On Wed, Sep 16, 2020 at 10:28:38AM +, Hongbo Wang wrote: > > > Hi Vladimir, > > > > > > if swp0 connects with customer, and swp1 connects with ISP, According > > > to the VSC99599_1_00_TS.pdf, swp0 and swp1 will have different > > > VLAN_POP_CNT && VLAN_AWARE_ENA, > > > > > > swp0 should set VLAN_CFG.VLAN_POP_CNT=0 && > > VLAN_CFG.VLAN_AWARE_ENA=0 > > > swp1 should set VLAN_CFG.VLAN_POP_CNT=1 && > > VLAN_CFG.VLAN_AWARE_ENA=1 > > > > > > but when set vlan_filter=1, current code will set same value for both > > > swp0 and swp1, for compatibility with existing code(802.1Q mode), so > > > add devlink to set swp0 and swp1 into different modes. > > > > But if you make VLAN_CFG.VLAN_AWARE_ENA=0, does that mean the switch > > will accept any 802.1ad VLAN, not only those configured in the VLAN database > > of the bridge? Otherwise said, after running the commands above, and I send > > a > > packet to swp0 having tpid:88A8 vid:101, then the bridge should not accept > > it. > > > > I might be wrong, but I thought that an 802.1ad bridge with > > vlan_filtering=1 behaves the same as an 802.1q bridge, except that it should > > filter VLANs using a different TPID (0x88a8 instead of 0x8100). > > I don't think the driver, in the way you're configuring it, does that, does > > it? > > hi Vladimir, > you can refer to "4.3.3.0.1 MAN Access Switch Example" in > VSC99599_1_00_TS.pdf, > By testing the case, if don't set VLAN_AWARE_ENA=0 for customer's port swp0, > the Q-in-Q feature can't work well. > > In order to distinguish the port for customer and for ISP, I add devlink > command, > Actually, I can modify the driver config directly, not using devlink, > but it will be not compatible with current code and user guide. I asked this on the Microchip Support portal: -[cut here]- VLAN filtering only on specific TPID I would like to configure a port with the following behavior: - The VLAN table should contain 802.1ad VLANs 1 and 10. VLAN ingress filtering should be enabled. - An untagged frame on ingress should be classified to 802.1ad (TAG_TYPE=1) VLAN ID 1 (the port-based VLAN). The frame should be accepted because 802.1ad VLAN 1 is in the VLAN table. - An ingress frame with 802.1Q (0x8100) header VLAN ID 100 should be classified to 802.1ad (TAG_TYPE=1) VLAN ID 1 (the port-based VLAN). The frame should be accepted because 802.1ad VLAN 1 is in the VLAN table. - An ingress frame with 802.1ad (0x88a8) header VLAN ID 10 should be classified to 802.1ad (TAG_TYPE=1) VLAN ID 10. The frame should be accepted because 802.1ad VLAN 10 is in the VLAN table. - An ingress frame with 802.1ad (0x88a8) header VLAN ID 100 should be classified to 802.1ad (TAG_TYPE=1) VLAN ID 100. The frame should be dropped because 802.1ad VLAN 100 is not in the VLAN table. How do I configure the switch to obtain this behavior? This is not what the "Provider Bridges and Q-in-Q Operation" chapter in the reference manual is explaining how to do. Instead, that chapter suggests to make VLAN_CFG.VLAN_AWARE_ENA = 0. But I don't want to do this, because I need to be able to drop the frames with 802.1ad VLAN ID 100 in the example above. -[cut here]- Judging from the fact that I received no answer whatsoever, I can only deduce that offloading an 8021ad bridge, at least one that has the semantics that Toshiaki Makita described here, https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=1a0b20b257326523ec2a6cb51dd6f26ef179eb84 is not possible with this hardware. So I think there's little left to do here. If it helps, I am fairly certain that the sja1105 can offer the requested services, if you play a little bit with the TPID and TPID2 values. Maybe that's a path forward for your patches, if you still want to add the generic support in switchdev and in DSA. Thanks, -Vladimir
RE: [EXT] Re: [PATCH v6 3/3] net: dsa: ocelot: Add support for QinQ Operation
> On Wed, Sep 16, 2020 at 10:28:38AM +, Hongbo Wang wrote: > > Hi Vladimir, > > > > if swp0 connects with customer, and swp1 connects with ISP, According > > to the VSC99599_1_00_TS.pdf, swp0 and swp1 will have different > > VLAN_POP_CNT && VLAN_AWARE_ENA, > > > > swp0 should set VLAN_CFG.VLAN_POP_CNT=0 && > VLAN_CFG.VLAN_AWARE_ENA=0 > > swp1 should set VLAN_CFG.VLAN_POP_CNT=1 && > VLAN_CFG.VLAN_AWARE_ENA=1 > > > > but when set vlan_filter=1, current code will set same value for both > > swp0 and swp1, for compatibility with existing code(802.1Q mode), so > > add devlink to set swp0 and swp1 into different modes. > > But if you make VLAN_CFG.VLAN_AWARE_ENA=0, does that mean the switch > will accept any 802.1ad VLAN, not only those configured in the VLAN database > of the bridge? Otherwise said, after running the commands above, and I send a > packet to swp0 having tpid:88A8 vid:101, then the bridge should not accept it. > > I might be wrong, but I thought that an 802.1ad bridge with > vlan_filtering=1 behaves the same as an 802.1q bridge, except that it should > filter VLANs using a different TPID (0x88a8 instead of 0x8100). > I don't think the driver, in the way you're configuring it, does that, does > it? hi Vladimir, you can refer to "4.3.3.0.1 MAN Access Switch Example" in VSC99599_1_00_TS.pdf, By testing the case, if don't set VLAN_AWARE_ENA=0 for customer's port swp0, the Q-in-Q feature can't work well. In order to distinguish the port for customer and for ISP, I add devlink command, Actually, I can modify the driver config directly, not using devlink, but it will be not compatible with current code and user guide. Thanks, hongbo
Re: [EXT] Re: [PATCH v6 3/3] net: dsa: ocelot: Add support for QinQ Operation
On Wed, Sep 16, 2020 at 10:28:38AM +, Hongbo Wang wrote: > Hi Vladimir, > > if swp0 connects with customer, and swp1 connects with ISP, According > to the VSC99599_1_00_TS.pdf, swp0 and swp1 will have different > VLAN_POP_CNT && VLAN_AWARE_ENA, > > swp0 should set VLAN_CFG.VLAN_POP_CNT=0 && VLAN_CFG.VLAN_AWARE_ENA=0 > swp1 should set VLAN_CFG.VLAN_POP_CNT=1 && VLAN_CFG.VLAN_AWARE_ENA=1 > > but when set vlan_filter=1, current code will set same value for both > swp0 and swp1, for compatibility with existing code(802.1Q mode), so > add devlink to set swp0 and swp1 into different modes. But if you make VLAN_CFG.VLAN_AWARE_ENA=0, does that mean the switch will accept any 802.1ad VLAN, not only those configured in the VLAN database of the bridge? Otherwise said, after running the commands above, and I send a packet to swp0 having tpid:88A8 vid:101, then the bridge should not accept it. I might be wrong, but I thought that an 802.1ad bridge with vlan_filtering=1 behaves the same as an 802.1q bridge, except that it should filter VLANs using a different TPID (0x88a8 instead of 0x8100). I don't think the driver, in the way you're configuring it, does that, does it? Thanks, -Vladimir
RE: [EXT] Re: [PATCH v6 3/3] net: dsa: ocelot: Add support for QinQ Operation
Hi Vladimir, > -Original Message- > From: Vladimir Oltean > Sent: 2020年9月16日 18:00 > To: Hongbo Wang > Cc: Xiaoliang Yang ; Po Liu ; > Mingkai Hu ; allan.niel...@microchip.com; Claudiu > Manoil ; Alexandru Marginean > ; Vladimir Oltean > ; Leo Li ; and...@lunn.ch; > f.faine...@gmail.com; vivien.dide...@gmail.com; da...@davemloft.net; > j...@resnulli.us; ido...@idosch.org; k...@kernel.org; > vinicius.go...@intel.com; niko...@cumulusnetworks.com; > ro...@cumulusnetworks.com; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; horatiu.vul...@microchip.com; > alexandre.bell...@bootlin.com; unglinuxdri...@microchip.com; > ivec...@redhat.com > Subject: [EXT] Re: [PATCH v6 3/3] net: dsa: ocelot: Add support for QinQ > Operation > > Caution: EXT Email > > Hi Hongbo, > > On Wed, Sep 16, 2020 at 05:48:45PM +0800, hongbo.w...@nxp.com wrote: > > From: "hongbo.wang" > > > > This feature can be test in the following case: > > Customer <-> swp0 <-> swp1 <-> ISP > > > > Customer will send and receive packets with single VLAN tag(CTAG), ISP > > will send and receive packets with double VLAN tag(STAG and CTAG). > > This refers to "4.3.3 Provider Bridges and Q-in-Q Operation" in > > VSC99599_1_00_TS.pdf. > > > > The related test commands: > > 1. > > devlink dev param set pci/:00:00.5 name qinq_port_bitmap \ value 2 > > cmode runtime 2. > > ip link add dev br0 type bridge vlan_protocol 802.1ad ip link set dev > > swp0 master br0 ip link set dev swp1 master br0 ip link set dev br0 > > type bridge vlan_filtering 1 3. > > bridge vlan del dev swp0 vid 1 pvid > > bridge vlan add dev swp0 vid 100 pvid untagged bridge vlan add dev > > swp1 vid 100 > > Result: > > Customer(tpid:8100 vid:111) -> swp0 -> swp1 -> ISP(STAG \ > > tpid:88A8 vid:100, CTAG tpid:8100 vid:111) > > ISP(tpid:88A8 vid:100 tpid:8100 vid:222) -> swp1 -> swp0 ->\ > > Customer(tpid:8100 vid:222) > > > > Signed-off-by: hongbo.wang > > --- > > Can you please explain what is the purpose of the devlink parameter command? > As far as I understand, the commands from step 2 and 3 should behave like > that, even without running the command at step 1. if swp0 connects with customer, and swp1 connects with ISP, According to the VSC99599_1_00_TS.pdf, swp0 and swp1 will have different VLAN_POP_CNT && VLAN_AWARE_ENA, swp0 should set VLAN_CFG.VLAN_POP_CNT=0 && VLAN_CFG.VLAN_AWARE_ENA=0 swp1 should set VLAN_CFG.VLAN_POP_CNT=1 && VLAN_CFG.VLAN_AWARE_ENA=1 but when set vlan_filter=1, current code will set same value for both swp0 and swp1, for compatibility with existing code(802.1Q mode), so add devlink to set swp0 and swp1 into different modes. Thanks, hongbo
