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 361A242AA9; Mon, 1 Dec 2025 21:49:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764625797; cv=none; b=IwNzEbO2JsfuvqjSqwY3zVhuHGokC/jItF0WBo1X8uch8fcVw9h/owJ92Rm20ftryLJHGKzUI+b8puiCUtpFuc1mMw7TC93NshpMPolT3wkAfFJp40OT26nkFn1eahvX4UWiuPJB4f1ksMbodt3ALi//5JKvZ60ibGS4cvqtouQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764625797; c=relaxed/simple; bh=Q9XtxSLd1rGac+cMYRtu+RfRV0V9DsrRe1YEZEWkg7Q=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=hZIQggAHGrNWeC4pYuCc/P8Ixa1KcU2w9T6SnRFJTktgDqNhtjSKib9REqu0ZPbm0GPqi1B/iS7H1kjSoysX3ntitrOMvtQJgOERUgpoxxHeHk9kLqFRZp28zyBKjqHm4r+V6G5A01oDLHeOgkUuYiEpI90AMTBq5OucGVawuXw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kFqHOOIb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kFqHOOIb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3957C4CEF1; Mon, 1 Dec 2025 21:49:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764625796; bh=Q9XtxSLd1rGac+cMYRtu+RfRV0V9DsrRe1YEZEWkg7Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kFqHOOIb5o6yJOFl7lHQmbj6GnpI0itWZmYPfKoZ/b/zUawWr8ATXpz5yEPvh05iG 8J3TpYGeHSJHncImg5AjGFSm/HApLKPF/a0YWVg4RfAjI7kts6B0pgIBDZfnfl1Tx8 /N8WdFjzII0IDjcSXpGB9MpMJ5l9ZUkz8eKQn7yQbrXfirFcWuXtrsyN2dN6bJo+Df WSrt+9fgEabudvQp2mIdRbpUtUQTQZoRDiIbXl4Cn32xdstZIEoHG/PH3tJenmpAlt 5iu8L1XWfGxhKCxtPG7yKr3nZPeUdTk8N0At6u4p4pLCTP1b9yffRJLluvkPe00FE1 jyiAG9Rwe3Yvg== Date: Mon, 1 Dec 2025 13:49:54 -0800 From: Jakub Kicinski To: Jiri Pirko Cc: Tariq Toukan , Eric Dumazet , Paolo Abeni , Andrew Lunn , "David S. Miller" , Donald Hunter , Jonathan Corbet , Saeed Mahameed , Leon Romanovsky , Mark Bloch , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-rdma@vger.kernel.org, Gal Pressman , Moshe Shemesh , Carolina Jubran , Cosmin Ratiu , Jiri Pirko , Randy Dunlap Subject: Re: [PATCH net-next V4 02/14] documentation: networking: add shared devlink documentation Message-ID: <20251201134954.6b8a8d48@kernel.org> In-Reply-To: References: <1764101173-1312171-1-git-send-email-tariqt@nvidia.com> <1764101173-1312171-3-git-send-email-tariqt@nvidia.com> <20251127201645.3d7a10f6@kernel.org> <20251128191924.7c54c926@kernel.org> Precedence: bulk X-Mailing-List: linux-doc@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 Mon, 1 Dec 2025 11:50:08 +0100 Jiri Pirko wrote: > >> I'm not sure I follow. If there is only one PF bound, there is 1:1 > >> relationship. Depends on how many PFs of the same ASIC you have. > > > >I'm talking about multi-PF devices. mlx5 supports multi-PF setup for > >NUMA locality IIUC. In such configurations per-PF parameters can be > >configured on PCI PF ports. > > Correct. IFAIK there is one PF devlink instance per NUMA node. You say "correct" and then disagree with what I'm saying. I said ports because a port is a devlink object. Not a devlink instance. > The shared instance on top would make sense to me. That was one of > motivations to introduce it. Then this shared instance would hold > netdev, vf representors etc. I don't understand what the shared instance is representing and how user is expect to find their way thru the maze of devlink instanced, for real bus, aux bus, and now shared instanced. > >> Well, the mutex protect the list of instances which are managed in the > >> driver. If you want to move the mutex, I don't see how to do it without > >> moving all the code related to shared devlink instances, including faux > >> probe etc. Is that what you suggest? > > > >Multiple ways you can solve it, but drivers should have to duplicate > >all the instance management and locking. BTW please don't use guard(). > > I'm having troubles to undestand what you say, sorry :/ Do you prefer to > move the code from driver to devlink core or not? I missed a "not".. drivers should _not_ have to duplicate, sorry. > Regarding guard(), sure. I wonder how much more time it's gonna take > since this resistentance fades out :) guard() locks code instead of data accesses. We used to make fun of Java in this community, you know.