From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 269637E for ; Thu, 4 May 2023 02:16:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CD03C4339C; Thu, 4 May 2023 02:16:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683166604; bh=PW+c9W1lKkqa0MGUEQOHm4KVa9/uzQUP2DqPlSFoTyA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ar9tY9+a1VSpkevOIpwMLxDvLwe71J3KkyKwwHlbpXI2yPggkJYL4FyRChYZYQRSj YY5lSk4VjkP3rnl8mmQVaSKni6q2RNrrjzzI8HPP3uK8NieR5lUxlkzrlhJ7Kgq8Ps yi3nAfPg1TgQHuZKpJ196ZMZJFt8I8dOvDFUyznn1KNDKB3JfyL4As8qj6JJ0O2Lcy VXtb/Fneb/cPYLrxpxEy3zmxuPjoxO/cmU9CAJdW9DGiQT3PMxL31mjjWXauVh2vNB 9wAQP3LOKdFi1co+sgQu3jc69LOfq3tVicNqhGdS/EwWTsdwrUedSQh9ZFq+x5yorx q+a/Lje3EvqVQ== Date: Wed, 3 May 2023 19:16:43 -0700 From: Jakub Kicinski To: Jiri Pirko Cc: "Kubalewski, Arkadiusz" , Vadim Fedorenko , Vadim Fedorenko , Jonathan Lemon , Paolo Abeni , poros , mschmidt , "netdev@vger.kernel.org" , linux-arm-kernel@lists.infradead.org, "linux-clk@vger.kernel.org" , "Olech, Milena" , "Michalik, Michal" Subject: Re: [PATCH RFC v6 2/6] dpll: Add DPLL framework base functions Message-ID: <20230503191643.12a6e559@kernel.org> In-Reply-To: References: <20230403111812.163b7d1d@kernel.org> <20230410153149.602c6bad@kernel.org> <20230417124942.4305abfa@kernel.org> <20230502083244.19543d26@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 3 May 2023 09:56:57 +0200 Jiri Pirko wrote: > >Yup, non-deterministic, just a cyclic ID allocated by the core starting > >from 1. Finding the right device / pin needs to be done via > >informational attributes not making assumptions about the ID. > > Okay. > > When netdev will have pin ID in the RT netlink message (as it is done > in RFCv7), it is easy to get the pin/dpll for netdev. No problem there. > > However, for non-SyncE usecase, how do you imagine scripts to work? > I mean, the script have to obtain dpll/pin ID by deterministic > module_name/clock_id/idx tuple. No scoped idx. > There are 2 options to do that: > 1) dump all dplls/pins and do lookup in userspace > 2) get a dpll/pin according to given module_name/clock_id/idx tuple > > The first approach is not very nice. > The currently pushed RFCv7 of the patchset does not support 2) > > Now if we add support for 2), we basically use module_name/clock_id/idx > as a handle for "get cmd". My point is, why can't we use it for "set > cmd" as well and avoid the ID entirely? Sure, we don't _have_ to have an ID, but it seems go against normal data normalization rules. And I don't see any harm in it. But you're asking for per-device "idx" and that's a no-go for me, given already cited experience. The user space can look up the ID based on identifying information it has. IMO it's better to support multiple different intelligible elements than single integer index into which drivers will start encoding all sort of info, using locally invented schemes.