Re: [PATCH net-next 0/3] nfp: support VF multi-queues configuration

From: Yinjun Zhang <yinjun.zhang@corigine.com>
To: Saeed Mahameed <saeed@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Simon Horman <simon.horman@corigine.com>,
	David Miller <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>,
	Michael Chan <michael.chan@broadcom.com>,
	Andy Gospodarek <andy@greyhouse.net>,
	Gal Pressman <gal@nvidia.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Edward Cree <ecree.xilinx@gmail.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Nole Zhang <peng.zhang@corigine.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	oss-drivers <oss-drivers@corigine.com>
Subject: Re: [PATCH net-next 0/3] nfp: support VF multi-queues configuration
Date: Sat, 29 Oct 2022 11:32:38 +0800	[thread overview]
Message-ID: <339fef36-8f3d-096a-8bd8-92bd2ff824f7@corigine.com> (raw)
In-Reply-To: <20221027104914.fasecsmjsksbrace@sx1>

On 2022/10/27 18:49, Saeed Mahameed wrote:
> On 27 Oct 09:46, Yinjun Zhang wrote:
>> On Thu, 27 Oct 2022 09:46:54 +0100, Saeed Mahameed wrote:
>> <...>
>>> if you want to go with q as a resource, then you will have to start
>>> assigning individual queues to vfs one by one.. hence q_table per VF 
>>> will
>>> make it easier to control q table size per vf, with max size and 
>>> guaranteed
>>> size.
>>
>> Excuse my foolishness, I still don't get your q_table. What I want is 
>> allocating
>> a certain amount of queues from a queue pool for different VFs, can you
>> provide an example of q_table?
>>
>
> queue pool and queue table are the same concept. Q as a resource is an
> individual entity, so it can't be used as the abstract.
> for simplicity you can just call the resource "queues" plural, maybe ..

I see, you're always standing on VF's point, so "queues" is just one of 
the VF's
properties, so that port way sounds better indeed. And I'm standing on
queues' point, and VFs happen to be its recipients.

> Also do we want to manage different queue types separately ?
> Rx/Tx/Cq/EQ/command etc ?

We didn't expect those variants in our case for now.

>
> how about the individual max sizes of these queues ?
> BTW do you plan to have further customization per VF? not in particular
> resource oriented customization, more like capability control type of
> configs, for example enabling/disabling crypto offloads per VF? admin
> policies ? etc .. If so i would be happy if we collaborated on 
> defining the APIs.

Not scheduled either.
I think it's better to introduce port param back, it's more flexible 
than port function
and can avoid frequent change to uAPIs.