Re: [PATCH v3 net-next 04/15] net: dsa: felix: add new VLAN-based tagger

From: Vladimir Oltean <olteanv@gmail.com>
To: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Richard Cochran <richardcochran@gmail.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Alexandru Marginean <alexandru.marginean@nxp.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	Hongbo Wang <hongbo.wang@nxp.com>, Po Liu <po.liu@nxp.com>,
	Yangbo Lu <yangbo.lu@nxp.com>,
	Maxim Kochetkov <fido_max@inbox.ru>,
	Eldar Gasanov <eldargasanov2@gmail.com>,
	Andrey L <al@b4comtech.com>,
	UNGLinuxDriver@microchip.com
Subject: Re: [PATCH v3 net-next 04/15] net: dsa: felix: add new VLAN-based tagger
Date: Tue, 19 Jan 2021 02:04:26 +0200	[thread overview]
Message-ID: <20210119000426.sf42ecoefafhy6lh@skbuf> (raw)
In-Reply-To: <20210118161731.2837700-5-olteanv@gmail.com>

On Mon, Jan 18, 2021 at 06:17:20PM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> 
> There are use cases for which the existing tagger, based on the NPI
> (Node Processor Interface) functionality, is insufficient.
> 
> Namely:
> - Frames injected through the NPI port bypass the frame analyzer, so no
>   source address learning is performed, no TSN stream classification,
>   etc.
> - Flow control is not functional over an NPI port (PAUSE frames are
>   encapsulated in the same Extraction Frame Header as all other frames)
> - There can be at most one NPI port configured for an Ocelot switch. But
>   in NXP LS1028A and T1040 there are two Ethernet CPU ports. The non-NPI
>   port is currently either disabled, or operated as a plain user port
>   (albeit an internally-facing one). Having the ability to configure the
>   two CPU ports symmetrically could pave the way for e.g. creating a LAG
>   between them, to increase bandwidth seamlessly for the system.
> 
> So, there is a desire to have an alternative to the NPI mode.
> 
> This patch brings an implementation of the software-defined tag_8021q.c
> tagger format, which also preserves full functionality under a
> vlan_filtering bridge (unlike sja1105, the only other user of
> tag_8021q).
> 
> It does this by using the TCAM engines for:
> - pushing the RX VLAN as a second, outer tag, on egress towards the CPU
>   port
> - redirecting towards the correct front port based on TX VLAN and
>   popping that on egress
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---

Should both taggers be reported as DSA_TAG_PROTO_OCELOT as I am doing in
the current patchset? Currently a kernel can only be built with one
tagger or the other. But it is not possible to e.g. rmmod one tagger and
insmod another one.

If we allow compilation of more than one tagger for the same hardware,
how do we select between them if both are built into the same kernel?