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 A2440C4321E for ; Fri, 2 Dec 2022 12:39:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233535AbiLBMjq (ORCPT ); Fri, 2 Dec 2022 07:39:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233519AbiLBMjk (ORCPT ); Fri, 2 Dec 2022 07:39:40 -0500 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62DEFD4AC0 for ; Fri, 2 Dec 2022 04:39:38 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id e13so6272351edj.7 for ; Fri, 02 Dec 2022 04:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8jC7da2W+ukwOwEQYKKMGcqvppPDfTMpCFP/Jwhh/vM=; b=GHGxMCzfJMseZVfpWvl2V28HsXKKWJ5d7TyS9GxoG/+yyEYois2e0x/n9fxVpQWhzy VoQUo45+HYBUh5NYCn0lscProp+UyJLEEClGrVdEUI6Eg77fMyGVk+T/YyueqYZIsCr/ ofhRf/ERvG3gYovGF2+x19GFUHgGqcgCW3Im0A4tfUDqYTQ8XmFc4j5IOdy8GMH05ukL HxURuO5SFuJRfFTkvK2b1eE6njo0XUz2lkYxeyYAxvKJRtrEFuetydHnFOJEN81QDsuR VATXulY4cPSio5xPRrOF+x8fBHteScBg2YnEZfoggQIYK9BU1iRRgYplvCPyHsmEAxwW sq8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8jC7da2W+ukwOwEQYKKMGcqvppPDfTMpCFP/Jwhh/vM=; b=OG0FYcLfrgB3dOW5CnSmTOHoDWAauKslwR2oppBq+/xgd2zv1SJFXgTAhBuZ3a9OQD SXIVYRevBnNo3Mc+z3p4jfeWTWlO3Fg+k68KgU1Q7NRzywrfXeB4luyen1FQEPYXfLEU vd/3AhvoUhtww1xuCiQTonovwy1I1ZAjLLQUPq30iMQU4vFrKj3V0SuwHofTPc7pnwIr juZHyPGtTdbQJmT1WSBxAYQMfM6phggBeqtICjgJIU4Kbx1JzvgNHsbt3j4uqZUUD6uk GocRxr5kvQEp6VtzO6a8Zzu6ysrs+71Cr3Re2t9QAfuhglyLwJJaZjWJkHDVFqZviFHy djMQ== X-Gm-Message-State: ANoB5plW6MxzUvlP3uAT9Z7I+4od+s/rITAYmF5uyS6wKvJOCx2W8HkX 28wEgEzBDGFL1qh+UjWG8YQApQ== X-Google-Smtp-Source: AA0mqf6z+SAK9/8ueehDS8BhD7X+jXXxouu9P3VguQ4xI3VPnvJECeOsrYAUbmy/WuIFMqFQW0zEDA== X-Received: by 2002:a50:ee19:0:b0:46b:51e6:2e69 with SMTP id g25-20020a50ee19000000b0046b51e62e69mr18990436eds.354.1669984776881; Fri, 02 Dec 2022 04:39:36 -0800 (PST) Received: from localhost (host-213-179-129-39.customer.m-online.net. [213.179.129.39]) by smtp.gmail.com with ESMTPSA id ky1-20020a170907778100b0072a881b21d8sm2951052ejc.119.2022.12.02.04.39.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 04:39:36 -0800 (PST) Date: Fri, 2 Dec 2022 13:39:35 +0100 From: Jiri Pirko To: "Kubalewski, Arkadiusz" Cc: Vadim Fedorenko , Jakub Kicinski , 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: References: <20221129213724.10119-1-vfedorenko@novek.ru> <20221129213724.10119-3-vfedorenko@novek.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Fri, Dec 02, 2022 at 12:27:35PM CET, arkadiusz.kubalewski@intel.com wrote: >>From: Jiri Pirko >>Sent: Wednesday, November 30, 2022 5:37 PM >>Tue, Nov 29, 2022 at 10:37:22PM CET, vfedorenko@novek.ru wrote: >>>From: Vadim Fedorenko [...] >>>+static int >>>+dpll_msg_add_pin_netifindex(struct sk_buff *msg, const struct >>dpll_pin_attr *attr) >>>+{ >>>+ unsigned int netifindex; // TODO: Should be u32? >>>+ >>>+ if (dpll_pin_attr_netifindex_get(attr, &netifindex)) >>>+ return 0; >>>+ if (nla_put_u32(msg, DPLLA_PIN_NETIFINDEX, netifindex)) >> >>I was thinking about this. It is problematic. DPLL has no notion of >>network namespaces. So if the driver passes ifindex, dpll/user has no >>clue in which network namespace it is (ifindexes ovelay in multiple >>namespaces). >> >>There is no easy/nice solution. For now, I would go without this and >>only have linkage the opposite direction, from netdev to dpll. > >Well, makes sense to me. >Although as I have checked `ip a` showed the same ifindex either if port was >in the namespace or not. That is not the problem. The problem is, that you can have following two netdevs with the same ifindex each in different netns. 1) netdev x: ifindex 8, netns ns1 2) netdev y: ifindex 8, netns ns2 >Isn't it better to let the user know ifindex, even if he has to iterate all >the namespaces he has created? Definitelly not. As I showed above, one ifindex may refer to multiple netdevice instances. [...] >>>+ DPLLA_NETIFINDEX, >> >>Duplicate, you have it under pin. > >The pin can have netifindex as pin signal source may originate there by >Clock recovery mechanics. >The dpll can have ifindex as it "owns" the dpll. DPLL is not owned by any netdevice. That does not make any sense. Netdevice may be "child" of the same PCI device as the dpll instance. But that's it. >Shall user know about it? probably nothing usefull for him, although >didn't Maciej Machnikowski asked to have such traceability? 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 86122C4321E for ; Fri, 2 Dec 2022 12:40:47 +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:In-Reply-To:MIME-Version:References: 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=PkJ/YT9+LN4Yh5Z1ANqe/A1sd/45MWjuTjPAYIHOzAE=; b=MotNRhsn6iFp7+ TUEdKaYeusyTjZv9a9MhtN4gVo7o+S4hbYvGVhR2pldHdseNDyEmtOoYQF/HD9wBHojsDsDf7arym b1B8AUeM//tlFCFxsEc+U9pxyBZn5PgAauiiTzrfgyNNqPBSmt/BSiqPNvKM/bBap7T4IatCRKqu0 Oa7f4DWpMAK4nPe97P/0r9+j4mcAL7GTuB7qXg/YpjLGxaNZrj2zRuHo8bLpypldMQ83aZ5Wg02Hn xQWEv2YXEmfWPWQ188fuFEPgh5D6QrVP0WUkUewlDeniT9N0RZCgD5XVM0xpQi9izH9/cMBgC8PSD 3KMJaZU+vp1Q6Y+Ptt6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p15KU-00GOBN-Qo; Fri, 02 Dec 2022 12:39:47 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p15KP-00GO8d-K8 for linux-arm-kernel@lists.infradead.org; Fri, 02 Dec 2022 12:39:44 +0000 Received: by mail-ed1-x535.google.com with SMTP id x2so6353985edd.2 for ; Fri, 02 Dec 2022 04:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8jC7da2W+ukwOwEQYKKMGcqvppPDfTMpCFP/Jwhh/vM=; b=GHGxMCzfJMseZVfpWvl2V28HsXKKWJ5d7TyS9GxoG/+yyEYois2e0x/n9fxVpQWhzy VoQUo45+HYBUh5NYCn0lscProp+UyJLEEClGrVdEUI6Eg77fMyGVk+T/YyueqYZIsCr/ ofhRf/ERvG3gYovGF2+x19GFUHgGqcgCW3Im0A4tfUDqYTQ8XmFc4j5IOdy8GMH05ukL HxURuO5SFuJRfFTkvK2b1eE6njo0XUz2lkYxeyYAxvKJRtrEFuetydHnFOJEN81QDsuR VATXulY4cPSio5xPRrOF+x8fBHteScBg2YnEZfoggQIYK9BU1iRRgYplvCPyHsmEAxwW sq8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8jC7da2W+ukwOwEQYKKMGcqvppPDfTMpCFP/Jwhh/vM=; b=zLIdidIxiJsgOjC2mXpbl/+ac3uy/BxfpFcLLOx9tpRuMRzxl/BG/Lf5+PK1WDSdRI of+Jmw9NbUsU8ckypuBgM/xZe+FfoIZZB5iEpdMn5hLFqrurUVq/hNNgJXvAtLEZdQ1G gB+uj2GfnZGBQ81lPUhEEeQVUWHeJrIi34gflIk1FBChv+W9u9ofk3FTr4IhQoaCu1Pi OOplPmVzNL5QmA1BE/6+ME5pemAG+QUBUwW+EXIF0nhjFYZrTErL0hJpFbNIxq+lFhtA SPuD5/421iX5WxRHY+ojIEhjcqeBcKRh3VfENVi0Fdn4zn3IKBTtuPRsN5yfWdusGZZe K1DQ== X-Gm-Message-State: ANoB5pnFEZI2B64eigtgh750EdrmsXe6Wd31jn1dOwlGtQZy4GCGYOCr 5PejFLF3fv/y3n4WveijPMoYIA== X-Google-Smtp-Source: AA0mqf6z+SAK9/8ueehDS8BhD7X+jXXxouu9P3VguQ4xI3VPnvJECeOsrYAUbmy/WuIFMqFQW0zEDA== X-Received: by 2002:a50:ee19:0:b0:46b:51e6:2e69 with SMTP id g25-20020a50ee19000000b0046b51e62e69mr18990436eds.354.1669984776881; Fri, 02 Dec 2022 04:39:36 -0800 (PST) Received: from localhost (host-213-179-129-39.customer.m-online.net. [213.179.129.39]) by smtp.gmail.com with ESMTPSA id ky1-20020a170907778100b0072a881b21d8sm2951052ejc.119.2022.12.02.04.39.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 04:39:36 -0800 (PST) Date: Fri, 2 Dec 2022 13:39:35 +0100 From: Jiri Pirko To: "Kubalewski, Arkadiusz" Cc: Vadim Fedorenko , Jakub Kicinski , 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: References: <20221129213724.10119-1-vfedorenko@novek.ru> <20221129213724.10119-3-vfedorenko@novek.ru> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221202_043941_909538_81DF9CCA X-CRM114-Status: GOOD ( 13.96 ) 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 Fri, Dec 02, 2022 at 12:27:35PM CET, arkadiusz.kubalewski@intel.com wrote: >>From: Jiri Pirko >>Sent: Wednesday, November 30, 2022 5:37 PM >>Tue, Nov 29, 2022 at 10:37:22PM CET, vfedorenko@novek.ru wrote: >>>From: Vadim Fedorenko [...] >>>+static int >>>+dpll_msg_add_pin_netifindex(struct sk_buff *msg, const struct >>dpll_pin_attr *attr) >>>+{ >>>+ unsigned int netifindex; // TODO: Should be u32? >>>+ >>>+ if (dpll_pin_attr_netifindex_get(attr, &netifindex)) >>>+ return 0; >>>+ if (nla_put_u32(msg, DPLLA_PIN_NETIFINDEX, netifindex)) >> >>I was thinking about this. It is problematic. DPLL has no notion of >>network namespaces. So if the driver passes ifindex, dpll/user has no >>clue in which network namespace it is (ifindexes ovelay in multiple >>namespaces). >> >>There is no easy/nice solution. For now, I would go without this and >>only have linkage the opposite direction, from netdev to dpll. > >Well, makes sense to me. >Although as I have checked `ip a` showed the same ifindex either if port was >in the namespace or not. That is not the problem. The problem is, that you can have following two netdevs with the same ifindex each in different netns. 1) netdev x: ifindex 8, netns ns1 2) netdev y: ifindex 8, netns ns2 >Isn't it better to let the user know ifindex, even if he has to iterate all >the namespaces he has created? Definitelly not. As I showed above, one ifindex may refer to multiple netdevice instances. [...] >>>+ DPLLA_NETIFINDEX, >> >>Duplicate, you have it under pin. > >The pin can have netifindex as pin signal source may originate there by >Clock recovery mechanics. >The dpll can have ifindex as it "owns" the dpll. DPLL is not owned by any netdevice. That does not make any sense. Netdevice may be "child" of the same PCI device as the dpll instance. But that's it. >Shall user know about it? probably nothing usefull for him, although >didn't Maciej Machnikowski asked to have such traceability? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel