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
| ||
|
Date: Tue, 20 Sep 2022 19:27:48 +0100 From: Edward Cree <ecree.xilinx@...il.com> To: Simon Horman <simon.horman@...igine.com>, David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com> Cc: netdev@...r.kernel.org, oss-drivers@...igine.com, Diana Wang <na.wang@...igine.com>, Peng Zhang <peng.zhang@...igine.com> Subject: Re: [PATCH/RFC net-next 2/3] devlink: Add new "max_vf_queue" generic device param On 20/09/2022 16:14, 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. I don't like this. If I'm correctly understanding, it hardcodes an assumption that lower-numbered VFs will be the ones with more queues, and also makes it difficult to change a VF's max-queues on the fly. Why not instead have a per-VF operation to set that VF's max queue count? Ideally through the VF representor, perhaps as an ethtool param/tunable, rather than devlink. Then the mechanism is flexible and makes no assumptions about policy. -ed
Powered by blists - more mailing lists