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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86BFDC63705 for ; Wed, 7 Dec 2022 17:00:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229901AbiLGRAT (ORCPT ); Wed, 7 Dec 2022 12:00:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229795AbiLGQ74 (ORCPT ); Wed, 7 Dec 2022 11:59:56 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D05DB6931C; Wed, 7 Dec 2022 08:59:43 -0800 (PST) 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 6A99D61ACE; Wed, 7 Dec 2022 16:59:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 496CBC433C1; Wed, 7 Dec 2022 16:59:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670432382; bh=UOTMAATjpNxXnTsgAzUbM8B4waAQT2pl6BE2XR4t/K4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XhC0mmciJkcpwLG7sYOOaGKrWKwIVpdwqR/Dn9xSR635jBTpIfxxIFXzwfXPYVpEz vGBuzGWW7ET8W+aDFMjo/7nqquvc5C14fBzF2ICGG5AHL3B1tPic0PhuElEjw5MePz dSGQz57sc87bI7czj63nZHx4zLOn8UmGQMh3IEmE76m18pKx/b9m2mltqiwwyA8t38 xX3r6WcL8IFg/Fft1OPCDBrsOr6TrDx7KzneN2T6feczbHYDqLBBpf/qgF4i0lOQLA sakSWPZtM/QutnbGlBUiCypq4x/a3Vcl3DdQl7k+tGNM2RgJ9kEkzJKqhnG29KJC6B RuZyGWjftleCw== Date: Wed, 7 Dec 2022 08:59:41 -0800 From: Jakub Kicinski To: Jiri Pirko Cc: "Kubalewski, Arkadiusz" , Vadim Fedorenko , Jonathan Lemon , Paolo Abeni , "netdev@vger.kernel.org" , Vadim Fedorenko , linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, "Olech, Milena" , "Michalik, Michal" Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Message-ID: <20221207085941.3b56bc8c@kernel.org> In-Reply-To: References: <20221202212206.3619bd5f@kernel.org> <20221205161933.663ea611@kernel.org> <20221206092705.108ded86@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 7 Dec 2022 14:10:42 +0100 Jiri Pirko wrote: > >> Why do we need this association at all? > > > >Someone someday may want netns delegation and if we don't have the > >support from the start we may break backward compat introducing it. > > Hmm. Can you imagine a usecase? Running DPLL control in a namespace / container. I mean - I generally think netns is overused, but yes, it's what containers use, so I think someone may want to develop their timer controller SW in as a container? > Link to devlink instance btw might be a problem. In case of mlx5, one > dpll instance is going to be created for 2 (or more) PFs. 1 per ConnectX > ASIC as there is only 1 clock there. And PF devlinks can come and go, > does not make sense to link it to any of them. If only we stuck to the "one devlink instance per ASIC", huh? :) > Thinking about it a bit more, DPLL itself has no network notion. The > special case is SyncE pin, which is linked to netdevice. Just a small > part of dpll device. And the netdevice already has notion of netns. > Isn't that enough? So we can't use devlink or netdev. Hm. So what do we do? Make DPLLs only visible in init_net? And require init_net admin? And when someone comes asking we add an explicit "move to netns" command to DPLL? 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 1079EC352A1 for ; Wed, 7 Dec 2022 17:00:49 +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=AVV7GJgxisZnKZ/FnHqDSLXNglUP2i/gFSaT7rN+hNY=; b=aP1B8GqK43REvW DqDcFcK75NLDG43c43hi8NCz4GBqCKRlDU46Had8bwg1ukKl5AW3n1a1i2Tn3zA7c2LKg6GTHOwDY AN5MYEVPAwJcAlmnlQvKHVfen2FEzLuN+Hlq3wuwTB5wTRrqtzBbM6qp6nZ69BlOsxrWvLMDOL81p kZlc6D/NEb0mIT7oxlHx6ZgJuZaVY/FVTeWI5zx7yyUvRDOXN0CpazkGwKCWUSaDng9x2x23FCGHH /ch9AYXBgKgeXq5D/7583eb0KBhc3m1UsfI+dEbbpy2JaQK85/eftNXjR1Ck5UX0Jvnh14s9ASPf2 uy4GLi00xvA33y5lI/PQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p2xlv-00740I-7y; Wed, 07 Dec 2022 16:59:51 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p2xln-0073vJ-OZ for linux-arm-kernel@lists.infradead.org; Wed, 07 Dec 2022 16:59:45 +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 55A5861B27; Wed, 7 Dec 2022 16:59:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 496CBC433C1; Wed, 7 Dec 2022 16:59:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670432382; bh=UOTMAATjpNxXnTsgAzUbM8B4waAQT2pl6BE2XR4t/K4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XhC0mmciJkcpwLG7sYOOaGKrWKwIVpdwqR/Dn9xSR635jBTpIfxxIFXzwfXPYVpEz vGBuzGWW7ET8W+aDFMjo/7nqquvc5C14fBzF2ICGG5AHL3B1tPic0PhuElEjw5MePz dSGQz57sc87bI7czj63nZHx4zLOn8UmGQMh3IEmE76m18pKx/b9m2mltqiwwyA8t38 xX3r6WcL8IFg/Fft1OPCDBrsOr6TrDx7KzneN2T6feczbHYDqLBBpf/qgF4i0lOQLA sakSWPZtM/QutnbGlBUiCypq4x/a3Vcl3DdQl7k+tGNM2RgJ9kEkzJKqhnG29KJC6B RuZyGWjftleCw== Date: Wed, 7 Dec 2022 08:59:41 -0800 From: Jakub Kicinski To: Jiri Pirko Cc: "Kubalewski, Arkadiusz" , Vadim Fedorenko , Jonathan Lemon , Paolo Abeni , "netdev@vger.kernel.org" , Vadim Fedorenko , linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, "Olech, Milena" , "Michalik, Michal" Subject: Re: [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Message-ID: <20221207085941.3b56bc8c@kernel.org> In-Reply-To: References: <20221202212206.3619bd5f@kernel.org> <20221205161933.663ea611@kernel.org> <20221206092705.108ded86@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221207_085943_873702_43F113B7 X-CRM114-Status: GOOD ( 15.99 ) 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 Wed, 7 Dec 2022 14:10:42 +0100 Jiri Pirko wrote: > >> Why do we need this association at all? > > > >Someone someday may want netns delegation and if we don't have the > >support from the start we may break backward compat introducing it. > > Hmm. Can you imagine a usecase? Running DPLL control in a namespace / container. I mean - I generally think netns is overused, but yes, it's what containers use, so I think someone may want to develop their timer controller SW in as a container? > Link to devlink instance btw might be a problem. In case of mlx5, one > dpll instance is going to be created for 2 (or more) PFs. 1 per ConnectX > ASIC as there is only 1 clock there. And PF devlinks can come and go, > does not make sense to link it to any of them. If only we stuck to the "one devlink instance per ASIC", huh? :) > Thinking about it a bit more, DPLL itself has no network notion. The > special case is SyncE pin, which is linked to netdevice. Just a small > part of dpll device. And the netdevice already has notion of netns. > Isn't that enough? So we can't use devlink or netdev. Hm. So what do we do? Make DPLLs only visible in init_net? And require init_net admin? And when someone comes asking we add an explicit "move to netns" command to DPLL? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel