Thread (30 messages) 30 messages, 4 authors, 2022-10-05

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

From: Petr Machata <petrm@nvidia.com>
Date: 2022-10-05 10:13:27
Also in: linux-arm-kernel, lkml

[off-list ref] writes:
Den Mon, Oct 03, 2022 at 10:22:48AM +0200 skrev Petr Machata:
quoted
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

[off-list ref] writes:
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help