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 smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (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 749A4C04FFE for ; Tue, 30 Apr 2024 01:59:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 1ECA2608D9; Tue, 30 Apr 2024 01:59:47 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id Z4_EhGRJLqsJ; Tue, 30 Apr 2024 01:59:46 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.34; helo=ash.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6B589608A3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1714442386; bh=h1ieZNm089U3B7gvU5qVkYdFuUFs5Tbh6K/92kkSP44=; h=Date:From:To:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=lkUvQXpIplNtOabTL5s29ASl8cNMWM4+Po3uYXjDnwDOF6hv8AWGy5rb4ttlzPLpT pq3025N+TmZJM+ZxqmM/dfvJP//wxzNdWUn4iAT+8c68O51/xAN2Wa9O1DvGB5jlAx XAT54f7FzjvLe5s+dRpvZd4L0KFA2VqQoP6vBTxsQ0YEXF+8bTYED2mx1ldXMfmR4R z4BkeWCTPME+NPk9MxLa1ICwwhlKRmcdp5SD2Ij6+8h23kdJc52n22GH3s7FaBo6i/ K9tnkImLcUdgXHzuA5KpU2qp8mx4Rczv5jQNTEwctoROzUDzbeWo+sRIDT8FJRmW8c tPfTH6c1SnHjA== Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp3.osuosl.org (Postfix) with ESMTP id 6B589608A3; Tue, 30 Apr 2024 01:59:46 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id 85C421BF20D for ; Tue, 30 Apr 2024 01:59:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 70759816F5 for ; Tue, 30 Apr 2024 01:59:45 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id SXLM-f4WVpov for ; Tue, 30 Apr 2024 01:59:44 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=kuba@kernel.org; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp1.osuosl.org B716A81589 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B716A81589 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by smtp1.osuosl.org (Postfix) with ESMTPS id B716A81589 for ; Tue, 30 Apr 2024 01:59:44 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 8EA0C611A1; Tue, 30 Apr 2024 01:59:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD9DFC116B1; Tue, 30 Apr 2024 01:59:42 +0000 (UTC) Date: Mon, 29 Apr 2024 18:59:41 -0700 From: Jakub Kicinski To: Przemek Kitszel Message-ID: <20240429185941.6229b944@kernel.org> In-Reply-To: <73ac167e-abc5-4e7b-96e3-7c6689b5665a@intel.com> References: <73ac167e-abc5-4e7b-96e3-7c6689b5665a@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714442383; bh=gmJV+eyXc5ullhBIXnJzh6zZc8wBJRfAl36OX7QTHVY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bbmBjX7kooxLeXCyoVnwZrgSBAgmhglSG6Cx0wtC+TYnkdSOo6h4SSp5csL91Q17E i8S5aFbNfT/17PyFCclVWqBz2qfGYiy+m4nyAtxvDH/o9p/0OrNoU7cLLVJdNTiI/F Bptd0ku/N4bcdzh/m74Inall2DhFYwmjNyrrgmvOKVsVrgpSoioPXtiClC0ocYDlQd cBC2tpQtfqoMayK9C0xJGlinzk7s9HwXGhiwbzG4aJFKUo4qQQ5+YYL60KnWgNi63L HtIbEqnmRU58O+T3e1e+lYj3toh59gg3vsWvUI2zzV7cBY4y9JfyNq1WpebNbErdaD YjzXJqbaaoXxw== X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dmarc=pass (p=none dis=none) header.from=kernel.org X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=bbmBjX7k Subject: Re: [Intel-wired-lan] [RFC net-next (what uAPI?) ice: add support for more than 16 RSS queues for VF X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pawel Chmielewski , Jiri Pirko , "netdev@vger.kernel.org" , "Knitter, Konrad" , Ahmed Zaki , "Samudrala, Sridhar" , "intel-wired-lan@lists.osuosl.org" , Simon Horman , Mateusz Polchlopek , "Nguyen, Anthony L" , Paolo Abeni Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Fri, 26 Apr 2024 15:22:02 +0200 Przemek Kitszel wrote: > ## devlink resources (with current API) > `devlink resource` is compelling, partially given the name sounds like a > perfect match. But when we dig just a little bit, the current Path+sizes > (min,max,step) is totally off to what is the most elegant picture of the > situation. In order to fit into existing uAPI, I would need to register > VFs as PF's resource, then GLOBAL LUT and PF LUT as a sub resource to > that (each VF gets two entries under it; plus two additional ones for > PF) I don't like it, I also feel like there is not that much use of > current resources API (it's not natural to use it for distribution, only > for limitation). Can you share more on how that would look like?=20 =46rom the description it does not sound so bad. Maybe with some CLI / UI changes it will be fine? > ## devlink resources (with extended API) > It is possible to extend current `devlink resource` so instead of only > Path+size, there would be also Path+Owner option to use. > The default state for ice driver would be that PFs owns PF LUTs, GLOBAL > LUTs are all free. >=20 > example proposed flow to assign a GLOBAL LUT to VF0 and PF LUT to VF1: > pf=3D0000:03:00.0 # likely more meaningful than VSI idx, but open for > vf0=3D0000:03:00.1 # suggestions > vf1=3D0000:03:00.2 > devlink resource set pci/$pf path /lut/lut_table_512 owner $pf > devlink resource set pci/$pf path /lut/lut_table_2048 owner free > devlink resource set pci/$pf path /lut/lut_table_512 owner $vf0 > devlink resource set pci/$pf path /lut/lut_table_2048 owner $vf1 Don't we want some level of over-subscription to be allowed? 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 B014E8F49 for ; Tue, 30 Apr 2024 01:59:43 +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=1714442383; cv=none; b=elRK4r1Wfg7HTyUhC0xWx+QH7TBH/6f6x/bMnqAa7VHlqA6uoaA3RaP1KOx/LPcLGzHAQL6KD4nw3ztxL7l+7KDwh8iz0lEobgic1n3BJq959IqUx9nex7RGbiSEmJy5QpiUPpBf8GGhva/Q6aHWvZIxSMV7RwmW0O8vzACYHF4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714442383; c=relaxed/simple; bh=gmJV+eyXc5ullhBIXnJzh6zZc8wBJRfAl36OX7QTHVY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QLAm/1XpySHXvA2EwHdlTCCTt9eWzFBhaMJbireHNI1U3fzzyB7IjXEDrxICZE2dpM1G/Va374Juo9M2Y63xBg2TK7N7r5uCIcfOIAmjcYPVwyT5DO51b8TSQed+BZeckNhQWQW6g6YRodRkNgGEK67Xy2cR4i+8yLU+eilIe9s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bbmBjX7k; 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="bbmBjX7k" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD9DFC116B1; Tue, 30 Apr 2024 01:59:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714442383; bh=gmJV+eyXc5ullhBIXnJzh6zZc8wBJRfAl36OX7QTHVY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bbmBjX7kooxLeXCyoVnwZrgSBAgmhglSG6Cx0wtC+TYnkdSOo6h4SSp5csL91Q17E i8S5aFbNfT/17PyFCclVWqBz2qfGYiy+m4nyAtxvDH/o9p/0OrNoU7cLLVJdNTiI/F Bptd0ku/N4bcdzh/m74Inall2DhFYwmjNyrrgmvOKVsVrgpSoioPXtiClC0ocYDlQd cBC2tpQtfqoMayK9C0xJGlinzk7s9HwXGhiwbzG4aJFKUo4qQQ5+YYL60KnWgNi63L HtIbEqnmRU58O+T3e1e+lYj3toh59gg3vsWvUI2zzV7cBY4y9JfyNq1WpebNbErdaD YjzXJqbaaoXxw== Date: Mon, 29 Apr 2024 18:59:41 -0700 From: Jakub Kicinski To: Przemek Kitszel Cc: "netdev@vger.kernel.org" , "intel-wired-lan@lists.osuosl.org" , "Knitter, Konrad" , "Samudrala, Sridhar" , "Brandeburg, Jesse" , Mateusz Polchlopek , Ahmed Zaki , "Simon Horman" , Michal Schmidt , Paolo Abeni , Jiri Pirko , Pawel Chmielewski , "Nguyen, Anthony L" Subject: Re: [RFC net-next (what uAPI?) ice: add support for more than 16 RSS queues for VF Message-ID: <20240429185941.6229b944@kernel.org> In-Reply-To: <73ac167e-abc5-4e7b-96e3-7c6689b5665a@intel.com> References: <73ac167e-abc5-4e7b-96e3-7c6689b5665a@intel.com> 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: quoted-printable On Fri, 26 Apr 2024 15:22:02 +0200 Przemek Kitszel wrote: > ## devlink resources (with current API) > `devlink resource` is compelling, partially given the name sounds like a > perfect match. But when we dig just a little bit, the current Path+sizes > (min,max,step) is totally off to what is the most elegant picture of the > situation. In order to fit into existing uAPI, I would need to register > VFs as PF's resource, then GLOBAL LUT and PF LUT as a sub resource to > that (each VF gets two entries under it; plus two additional ones for > PF) I don't like it, I also feel like there is not that much use of > current resources API (it's not natural to use it for distribution, only > for limitation). Can you share more on how that would look like?=20 =46rom the description it does not sound so bad. Maybe with some CLI / UI changes it will be fine? > ## devlink resources (with extended API) > It is possible to extend current `devlink resource` so instead of only > Path+size, there would be also Path+Owner option to use. > The default state for ice driver would be that PFs owns PF LUTs, GLOBAL > LUTs are all free. >=20 > example proposed flow to assign a GLOBAL LUT to VF0 and PF LUT to VF1: > pf=3D0000:03:00.0 # likely more meaningful than VSI idx, but open for > vf0=3D0000:03:00.1 # suggestions > vf1=3D0000:03:00.2 > devlink resource set pci/$pf path /lut/lut_table_512 owner $pf > devlink resource set pci/$pf path /lut/lut_table_2048 owner free > devlink resource set pci/$pf path /lut/lut_table_512 owner $vf0 > devlink resource set pci/$pf path /lut/lut_table_2048 owner $vf1 Don't we want some level of over-subscription to be allowed?