Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Hongbo Wang <hongbo.wang@nxp.com>
To:     Vladimir Oltean <olteanv@gmail.com>
CC:     Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
        "allan.nielsen@microchip.com" <allan.nielsen@microchip.com>,
        Po Liu <po.liu@nxp.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        Alexandru Marginean <alexandru.marginean@nxp.com>,
        Vladimir Oltean <vladimir.oltean@nxp.com>,
        Leo Li <leoyang.li@nxp.com>, Mingkai Hu <mingkai.hu@nxp.com>,
        "andrew@lunn.ch" <andrew@lunn.ch>,
        "f.fainelli@gmail.com" <f.fainelli@gmail.com>,
        "vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "jiri@resnulli.us" <jiri@resnulli.us>,
        "idosch@idosch.org" <idosch@idosch.org>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "vinicius.gomes@intel.com" <vinicius.gomes@intel.com>,
        "nikolay@cumulusnetworks.com" <nikolay@cumulusnetworks.com>,
        "roopa@cumulusnetworks.com" <roopa@cumulusnetworks.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "horatiu.vultur@microchip.com" <horatiu.vultur@microchip.com>,
        "alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
        "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
        "ivecera@redhat.com" <ivecera@redhat.com>
Subject: RE: [EXT] Re: [PATCH v3 2/2] net: dsa: ocelot: Add support for QinQ
 Operation
Thread-Topic: [EXT] Re: [PATCH v3 2/2] net: dsa: ocelot: Add support for QinQ
 Operation
Thread-Index: AQHWYBLysSTEQPz7eU+nSm5YKzLQAakTjicAgAD0qUA=
Date:   Thu, 23 Jul 2020 04:05:10 +0000
Message-ID: <VI1PR04MB5103C716DBB73ABA72D8131EE1760@VI1PR04MB5103.eurprd04.prod.outlook.com>
References: <20200722103200.15395-1-hongbo.wang@nxp.com>
 <20200722103200.15395-3-hongbo.wang@nxp.com>
 <20200722125352.qbllow6pm6za5pq4@skbuf>
In-Reply-To: <20200722125352.qbllow6pm6za5pq4@skbuf>
Accept-Language: zh-CN, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ee12ca6e-fc4f-4670-a42e-08d82ebd9806
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2020 04:05:10.5614
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LdlSUumxgHbhxrUE6D7ssBGMiilyIZw6YyT73b7z8nTR4m4XwVl/xaHAVKmC/VFhi30IzgWsZyQAlc6sN7xq3g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5245
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> Instead of writing a long email, let me just say this.
> I ran your commands on 2 random network cards (not ocelot/felix ports).
> They don't produce the same results as you. In fact, no frame with VLAN
> 111 C-TAG is forwarded (or received) at all by the bridge, not to mention=
 that
> no VLAN 1000 S-TAG is pushed on egress.
>=20
>=20
> Have you tried playing with these commands?
>=20
> ip link add dev br0 type bridge vlan_filtering 1 vlan_protocol 802.1ad ip=
 link
> set eth0 master br0 ip link set eth1 master br0 bridge vlan add dev eth0 =
vid
> 100 pvid bridge vlan add dev eth1 vid 100
>=20
> They produce the same output as yours, but have the benefit of using the
> network stack's abstractions and not glue between the 802.1q and the brid=
ge
> module, hidden in the network driver.
>=20
> I am sending the following packet towards eth0:
>=20
> 00:04:9f:05:f4:ad > 00:01:02:03:04:05, ethertype 802.1Q (0x8100), length
> 102: \
>         vlan 111, p 0, ethertype IPv4, 10.0.111.1 > 10.0.111.3: \
>         ICMP echo request, id 63493, seq 991, length 64
>=20
> and collecting it on the partner of eth1 as follows:
>=20
> 00:04:9f:05:f4:ad > 00:01:02:03:04:05, ethertype 802.1Q-QinQ (0x88a8),
> length 106: \
>         vlan 100, p 0, ethertype 802.1Q, vlan 111, p 0, ethertype IPv4, \
>         10.0.111.1 > 10.0.111.3: ICMP echo request, id 63493, seq 991,
> length 64
>=20
> Thanks,
> -Vladimir

Hi Vladimir,
  the command " ip link add dev br0 type bridge vlan_filtering 1 vlan_proto=
col=20
802.1ad " will influence all ports within the bridge, it will enable all po=
rts vlan_filtering
flag and 802.1ad mode, if ocelot port enable vlan_filtering, it will set VL=
AN_AWARE_ENA
and VLAN_POP_CNT(1), the code is in ocelot_port_vlan_filtering in ocelot.c.=
 it will
pop one tag from ingress frame, it's not my need, so I don't set vlan_filte=
ring.

  If enable vlan_filtering, it needs enable VCAP ES0 push double VLAN tag, =
the code
is in another patch, it's based on VCAP ES0 related code, I will post it af=
ter ES0 code
be accepted.

  In this case, I only want the egress port(swp1) in QinQ mode, the mode wi=
ll change swp1's
REW_TAG value, don't need swp0 enter QinQ mode, another issue is that if us=
e " ip link add dev=20
br0 type bridge ...", it can't pass proto to port driver, in dsa_slave_vlan=
_rx_add_vid, it will walk
into here:
		ret =3D br_vlan_get_info(dp->bridge_dev, vid, &info);
		if (ret =3D=3D 0)  // ret is 0
			return -EBUSY;
so I use "ip link add link swp1 name swp1.111 type vlan protocol 802.1ad id=
 111" to enable only
port swp1's QinQ mode.

Thanks,
hongbo