From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 19A45C433FE for ; Mon, 3 Oct 2022 23:36:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=z+L4gyM7c4TN6EBor45BDSUUeOaqW2mMqDlapoESRTA=; b=HCww3dP5xIBsOh Ql9BSLiCqMh8cPLFZGpPhwsUfiq3hU++3U3ZesA3tpjxyrplmsihjub6JJdqBA49GOm3STcm8Iu2H x0gqZdr5j4XtIKB3WyJxOWh4fenNKZ/HRu+Fu1m9493AmoWr0Zd9HMtl9JUYJBJrtO1uxcP7PuLC+ RDRfRe0zAilWhWfx+GpF6qG1zLygMXiXYg8Hq8tBi+qxQb7zhbbkAg7mP146EcJPnGkoMiqtR0i/4 tXqlJMFaIkpUKH9GisGG/4kf8NIgaKb/4bw0eBbb1TDlig3Nx0q3GtZrh425qnh8mvg6CbSgVhgGY ejnR48hr1MjOukqCDcoA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ofUxd-0083Vw-NH; Mon, 03 Oct 2022 23:34:57 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ofUxb-0083VY-Hv for linux-arm-kernel@lists.infradead.org; Mon, 03 Oct 2022 23:34:56 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 06C8F61070; Mon, 3 Oct 2022 23:34:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCA23C433C1; Mon, 3 Oct 2022 23:34:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664840092; bh=DM9gkSKKb8UHctPavkKh9d4DtvTG7D6IhOkgdAnQjmQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=K1W5m0WdFXAF7UPCmXehc+jkBtL/EZf36Ki50wZM4Q8086Dzp65pruvZFVd1tuxn8 v3Ld4VGnHcT0NiTGDNuceo1CuUY7wzNCygCTwBDZVd6luh/pVFYnKvSpFqgDhyasrz AY81lexkAC7+irLyAA/CPpqcnCs7GG/i7AS0avOONfVxYvjoJNqqpcCxWku8A+QESc frYTP8YQaEV3YnWZm+Nrkr3+9iZdnnTiVjSzeciG84QV3G/cFdBty4DtNu5HvHCDMm 9XDfeOph0wFAYUfYfX0mkdboavR1pYbp/Kl5QysylWEiGidgNTFFXrQ5MHXqugdJ2X Zz2PaGWRd/QiA== Date: Mon, 3 Oct 2022 16:34:50 -0700 From: Jakub Kicinski To: Cc: , , , , , , , , , , , , , , , , Subject: Re: [PATCH net-next v2 1/6] net: dcb: add new pcp selector to app object Message-ID: <20221003163450.7e6cbf3a@kernel.org> In-Reply-To: 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> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221003_163455_682836_47178734 X-CRM114-Status: GOOD ( 15.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel