Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 8 Nov 2022 12:08:51 +0200
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Felix Fietkau <nbd@nbd.name>
Cc:     netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 08/14] net: vlan: remove invalid VLAN protocol warning
Message-ID: <20221108100851.tl5aqhmbc5altdwv@skbuf>
References: <20221107185452.90711-1-nbd@nbd.name>
 <20221107185452.90711-8-nbd@nbd.name>
 <20221107215745.ascdvnxqrbw4meuv@skbuf>
 <3b275dda-39ac-282d-8a46-d3a95fdfc766@nbd.name>
 <20221108090039.imamht5iyh2bbbnl@skbuf>
 <0948d841-b0eb-8281-455a-92f44586e0c0@nbd.name>
 <20221108094018.6cspe3mkh3hakxpd@skbuf>
 <a9109da1-ba49-d8f4-1315-278e5c890b99@nbd.name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a9109da1-ba49-d8f4-1315-278e5c890b99@nbd.name>
Precedence: bulk

On Tue, Nov 08, 2022 at 10:46:54AM +0100, Felix Fietkau wrote:
> I think it depends on the hardware. If you can rely on the hardware always
> reporting the port out-of-band, a generic "oob" tagger would be fine.
> In my case, it depends on whether a second non-DSA ethernet MAC is active on
> the same device, so I do need to continue using the "mtk" tag driver.

It's not only about the time dimension (always OOB, vs sometimes OOB),
but also about what is conveyed through the OOB tag. I can see 2 vendors
agreeing today on a common "oob" tagger only to diverge in the future
when they'll need to convey more information than just port id. What do
you do with the tagging protocol string names then. Gotta make them
unique from the get go, can't export "oob" to user space IMO.

> The flow dissector part is already solved: I simply used the existing
> .flow_dissect() tag op.

Yes, well this seems like a generic enough case (DSA offload tag present
=> don't shift network header because it's where it should be) to treat
it in the generic flow dissector and not have to invoke any tagger-specific
fixup method.