Messages in this thread | | | Date | Mon, 3 Oct 2022 16:34:50 -0700 | From | Jakub Kicinski <> | Subject | Re: [PATCH net-next v2 1/6] net: dcb: add new pcp selector to app object |
| |
On Mon, 3 Oct 2022 21:59:49 +0000 Daniel.Machon@microchip.com wrote: > If lldpad was idd able to emit the new pcp app entries, they would be
idd?
> emitted as invalid TLV's (assuming 255 or 24 selector value), because the > selector would be either zero or seven, which is currently not used for > any selector by the std. We then have time to patch lldpad to do whatever > with the new attr. Wouldn't this be acceptable?
I'm not sure I can provide sensible advice given I don't really know how the information flow looks in case of DCB.
First off - we're talking about netlink TLVs not LLDP / DCB wire message TLVs?
What I was saying is that if lldpad dumps the information from the kernel and gets confused by certain TLVs - we can add an opt-in attribute to whatever Netlink request lldpad uses, and only add the new attrs if that opt-in attribute is present. Normal GET or DUMP requests can both take input attributes.
Old lldpad will not send this attribute to the kernel - the kernel will not respond with confusing attrs. The new lldpad can be patched to send the attribute and will get all the attrs (if it actually cares).
| |