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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 Oct 2022 11:49:14 +0100
From:   Saeed Mahameed <saeed@...nel.org>
To:     Yinjun Zhang <yinjun.zhang@...igine.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Simon Horman <simon.horman@...igine.com>,
        David Miller <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Gal Pressman <gal@...dia.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Tony Nguyen <anthony.l.nguyen@...el.com>,
        Edward Cree <ecree.xilinx@...il.com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Andrew Lunn <andrew@...n.ch>,
        Nole Zhang <peng.zhang@...igine.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        oss-drivers <oss-drivers@...igine.com>
Subject: Re: [PATCH net-next 0/3] nfp: support VF multi-queues configuration

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 .. 

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

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.

><...>
>>
>> Thanks, good to know it's not a FW/ASIC constraint,
>> I am trying to push for one unified orchestration model for all VFs,SFs and
>> the
>> upcoming intel's SIOV function.
>>
>> create->configure->deploy. This aligns with all standard virtualization
>> orchestration modles, libvirt, kr8, etc ..
>>
>> Again i am worried we will have to support a config query for ALL possible
>> functions prior to creation.
>>
>> Anyway i am flexible, I am ok with having a configure option prior to
>> creation as long as it doesn't create clutter, and user confusion, and it's
>> semantically correct.
>
>Thanks for your ok and thanks to Leon's explanation, I understand your
>create->config->deploy proposal. But I have to say the resource way
>doesn't break it, you can config it after creating, and it's not constrained
>to it, you can config it before creating as well.
>

Think about the poor admin who will need to have different config steps for
different port flavors.