Hi Hongbo, On Thu, Sep 17, 2020 at 02:37:59AM +0000, Hongbo Wang wrote: > > On Wed, Sep 16, 2020 at 10:28:38AM +0000, 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
