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?