netdev - Re: [PATCH net-next 2/3] devlink: Add new "max_vf

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]

Message-ID: <20221024014713.GA20243@nj-rack01-04.nji.corigine.com>
Date:   Mon, 24 Oct 2022 09:47:13 +0800
From:   Yinjun Zhang <yinjun.zhang@...igine.com>
To:     Gal Pressman <gal@...dia.com>
Cc:     Simon Horman <simon.horman@...igine.com>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Saeed Mahameed <saeed@...nel.org>,
        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 2/3] devlink: Add new "max_vf_queue" generic
 device param

On Sun, Oct 23, 2022 at 02:28:24PM +0300, Gal Pressman wrote:
> [Some people who received this message don't often get email from gal@...dia.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On 19/10/2022 17:09, Simon Horman wrote:
> > From: Peng Zhang <peng.zhang@...igine.com>
> >
> > VF max-queue-number is the MAX num of queues which the VF has.
> >
> > Add new device generic parameter to configure the max-queue-number
> > of the each VF to be generated dynamically.
> >
> > The string format is decided ad vendor specific. The suggested
> > format is ...-V-W-X-Y-Z, the V represents generating V VFs that
> > have 16 queues, the W represents generating W VFs that have 8
> > queues, and so on, the Z represents generating Z VFs that have
> > 1 queue.
> 
> Having a vendor specific string contradicts the point of having a
> generic parameter, why not do it as a vendor param, or generalize the
> string?

As Jakub suggested, we'll try to utilize devlink resource API instead.

> 
> >
> > For example, to configure
> > * 1x VF with 128 queues
> > * 1x VF with 64 queues
> > * 0x VF with 32 queues
> > * 0x VF with 16 queues
> > * 12x VF with 8 queues
> > * 2x VF with 4 queues
> > * 2x VF with 2 queues
> > * 0x VF with 1 queue, execute:
> >
> > $ devlink dev param set pci/0000:01:00.0 \
> >                           name max_vf_queue value \
> >                           "1-1-0-0-12-2-2-0" cmode runtime
> >
> > When created VF number is bigger than that is configured by this
> > parameter, the extra VFs' max-queue-number is decided as vendor
> > specific.
> >
> > If the config doesn't be set, the VFs' max-queue-number is decided
> > as vendor specific.
> >
> > Signed-off-by: Peng Zhang <peng.zhang@...igine.com>
> > Signed-off-by: Simon Horman <simon.horman@...igine.com>
> >
> 
> Does this command have to be run before the VFs are created? What
> happens to existing VFs?

Yes in our current implementation, but it's up to the vendor's
implementation I think.