[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5056c692-7478-4f38-8859-7cc7c823bbf5@intel.com>
Date: Tue, 2 Sep 2025 14:24:07 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Saeed Mahameed <saeed@...nel.org>, Jakub Kicinski <kuba@...nel.org>
CC: "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>,
<netdev@...r.kernel.org>, Tariq Toukan <tariqt@...dia.com>, Gal Pressman
<gal@...dia.com>, Leon Romanovsky <leonro@...dia.com>, Jiri Pirko
<jiri@...dia.com>, Simon Horman <horms@...nel.org>, Vlad Dumitrescu
<vdumitrescu@...dia.com>, Kamal Heib <kheib@...hat.com>
Subject: Re: [PATCH net-next V6 01/13] devlink: Add 'total_vfs' generic device
param
On 7/9/2025 10:38 PM, Saeed Mahameed wrote:
> On 09 Jul 19:53, Jakub Kicinski wrote:
>> On Tue, 8 Jul 2025 20:04:43 -0700 Saeed Mahameed wrote:
>>> + * - ``total_vfs``
>>> + - u32
>>> + - The total number of Virtual Functions (VFs) supported by the PF.
>>
>> "supported" is not the right word for a tunable..
>
> From kernel Doc:
>
> int pci_sriov_get_totalvfs(struct pci_dev *dev)
> get total VFs _supported_ on this device
>
> Anyway:
> "supported" => "exposed" ?
>
>
The parameter relates to the maximum number of VFs you could create. It
sounds like this hardware by default sets to 0, and you can change that
in the NVM with external tools. This adds a devlink parameter to allow
setting to be changed from the kernel tools.
exposed seems reasonable to me. You could also have language that
explains this is about a maximum, since this changes the value reported
by pci_sriov_get_totalvfs. You still have the usual means to
enable/disable VFs via the standard PCI interfaces.
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)
Powered by blists - more mailing lists