Re: [PATCH net-next v2 1/6] net: dcb: add new pcp selector to app object

From: Petr Machata <petrm@nvidia.com>
To: <Daniel.Machon@microchip.com>
Cc: <petrm@nvidia.com>, <netdev@vger.kernel.org>,
	<davem@davemloft.net>, <maxime.chevallier@bootlin.com>,
	<thomas.petazzoni@bootlin.com>, <edumazet@google.com>,
	<kuba@kernel.org>, <pabeni@redhat.com>,
	<Lars.Povlsen@microchip.com>, <Steen.Hegelund@microchip.com>,
	<UNGLinuxDriver@microchip.com>, <joe@perches.com>,
	<linux@armlinux.org.uk>, <Horatiu.Vultur@microchip.com>,
	<Julia.Lawall@inria.fr>, <vladimir.oltean@nxp.com>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH net-next v2 1/6] net: dcb: add new pcp selector to app object
Date: Wed, 5 Oct 2022 12:09:07 +0200	[thread overview]
Message-ID: <87bkqqwpcj.fsf@nvidia.com> (raw)
In-Reply-To: <YzquziZD+T145jo0@DEN-LT-70577>

<Daniel.Machon@microchip.com> writes:

> Den Mon, Oct 03, 2022 at 10:22:48AM +0200 skrev Petr Machata:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> 
>> <Daniel.Machon@microchip.com> writes:
>> 
>> > Right, I see your point. But. First thought; this starts to look a little
>> > hackish.
>> 
>> So it is. That's what poking backward compatible holes in an existing
>> API gets you. Look at modern C++ syntax for an extreme example :)
>> 
>> But read Jakub's email. It looks like we don't actually need to worry
>> about this.
>> 
>> > Looking through the 802.1Q-2018 std again, sel bits 0, 6 and 7 are
>> > reserved (implicit for future standard implementation?). Do we know of
>> > any cases, where a new standard version would introduce new values beyond
>> > what was reserved in the first place for future use? I dont know myself.
>> >
>> > I am just trying to raise a question of whether using the std APP attr
>> > with a new high (255) selector, really could be preferred over this new
>> > non-std APP attr with new packed payload.
>> 
>> Yeah. We'll need to patch lldpad anyway. We can basically choose which
>> way we patch it. And BTW, using the too-short attribute payload of
>> course breaks it _as well_, because they don't do any payload size
>> validation.
>
> Right, unless we reconstruct std app entry payload from the "too-short"
> attribute payload, before adding it the the app list or passing it to the 
> driver.

The issue is not in drivers, but in lldpad itself. They just iterate the
attribute stream, assume that everything is an APP, and treat is as
such, not even validating the length (I mean, why would they, it's
supposed to be an APP after all...).

So we trip lldpad however we set the API up.

So let's trip it in a way that makes for a reasonable API.

> Anyway. Considering Jakub's mail. I think this patch version with a non-std
> attribute to do non-std app table contributions separates non-std from std
> stuff nicely and is preffered over just adding the new selector. So if we can 
> agree on this, I will prepare a new v. with the other changes suggested.
>
> Wrt. lldpad we can then patch it to react on attrs or selectors > 7.

Yep, agreed.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel