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;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.117.160 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.117.160; helo=mail.nvidia.com; pr=C
References: <20220929185207.2183473-1-daniel.machon@microchip.com>
 <20220929185207.2183473-2-daniel.machon@microchip.com>
 <87leq1uiyc.fsf@nvidia.com> <20220930175452.1937dadd@kernel.org>
 <87pmf9xrrd.fsf@nvidia.com> <20221003092522.6aaa6d55@kernel.org>
 <YztdsF6b6SM9E5rw@DEN-LT-70577> <20221003163450.7e6cbf3a@kernel.org>
User-agent: mu4e 1.6.6; emacs 28.1
From:   Petr Machata <petrm@nvidia.com>
To:     Jakub Kicinski <kuba@kernel.org>
CC:     <Daniel.Machon@microchip.com>, <petrm@nvidia.com>,
        <netdev@vger.kernel.org>, <davem@davemloft.net>,
        <maxime.chevallier@bootlin.com>, <thomas.petazzoni@bootlin.com>,
        <edumazet@google.com>, <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:   Tue, 4 Oct 2022 12:56:35 +0200
In-Reply-To: <20221003163450.7e6cbf3a@kernel.org>
Message-ID: <87r0znx363.fsf@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2022 11:02:28.3682
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 503fd27e-fca6-4e7c-9be8-08daa5f7ed66
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.160];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT072.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6608
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


Jakub Kicinski <kuba@kernel.org> writes:

> 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?

DCB wire message in this case.

> 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).

Another aspect is that lldpad will never create these entries on its
own, until it gets support for it, at which point these issues would
presumably get fixed as well. The only scenario in which it breaks is
when an admin messes with the APP entries through iproute2, but then
uses lldpad. Which doesn't make sense to me as a use case.