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:   Tue, 25 Oct 2022 08:51:41 +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>,
        Peng Zhang <peng.zhang@...igine.com>, netdev@...r.kernel.org,
        oss-drivers@...igine.com
Subject: Re: [PATCH net-next 0/3] nfp: support VF multi-queues configuration

On 20 Oct 09:35, Yinjun Zhang wrote:
>On Wed, Oct 19, 2022 at 06:01:06PM -0700, Jakub Kicinski wrote:
>> On Wed, 19 Oct 2022 16:09:40 +0200 Simon Horman wrote:
>> > this short series adds the max_vf_queue generic devlink device parameter,
>> > the intention of this is to allow configuration of the number of queues
>> > associated with VFs, and facilitates having VFs with different queue
>> > counts.
>> >
>> > The series also adds support for multi-queue VFs to the nfp driver
>> > and support for the max_vf_queue feature described above.
>>
>> I appreciate CCing a wider group this time, but my concerns about using
>> devlink params for resource allocation still stand. I don't remember
>> anyone refuting that.
>>
>> https://lore.kernel.org/all/20220921063448.5b0dd32b@kernel.org/
>
>Sorry this part was neglected, we'll take a look into the resource APIs.
>Thanks.
>

The problem with this is that this should be a per function parameter,
devlink params or resources is not the right place for this as this
should be a configuration of a specific devlink object that is not the
parent device (namely devlink port function), otherwise we will have to
deal with ugly string parsing to address the specific vf attributes. 

let's use devlink port:
https://www.kernel.org/doc/html/latest/networking/devlink/devlink-port.html

devlink ports have attributes and we should extend attributes to act like
devlink parameters.

   devlink port function set DEV/PORT_INDEX [ queue_count count ] ...

https://man7.org/linux/man-pages/man8/devlink-port.8.html

Alternatively you should also consider limiting vf msix, as we did in mlx5
https://patchwork.kernel.org/project/linux-rdma/cover/20210314124256.70253-1-leon@kernel.org/