netdev - Re: [Intel-wired-lan] [PATCH iwl-next v4 0/5] iavf: Add devlink and devlink rate support'

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: <340b7306b5adbdba468c1cf719c912cbeeb12df6.camel@redhat.com>
Date: Fri, 15 Dec 2023 12:47:21 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, anthony.l.nguyen@...el.com, 
 intel-wired-lan@...ts.osuosl.org, qi.z.zhang@...el.com, Wenjun Wu
 <wenjun1.wu@...el.com>, maxtram95@...il.com, "Chittim, Madhu"
 <madhu.chittim@...el.com>, "Samudrala, Sridhar"
 <sridhar.samudrala@...el.com>,  Simon Horman <simon.horman@...hat.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 0/5] iavf: Add devlink and
 devlink rate support'

On Fri, 2023-12-15 at 12:06 +0100, Paolo Abeni wrote:
> 1) AFAICS devlink (and/or devlink_port) does not have fine grained, per
> queue representation and intel want to be able to configure shaping on
> per queue basis. I think/hope we don't want to bring the discussion to
> extending the devlink interface with queue support, I fear that will
> block us for a long time. Perhaps I’m missing or misunderstanding
> something here. Otherwise in retrospect this looks like a reasonable
> point to completely avoid devlink here.

Note to self: never send a message to the ML before my 3rd morning
coffee.

This thread started with Intel trying to using devlink rate for their
use-case, apparently slamming my doubt above.

My understanding is that in the patches the queue devlink <> queue
relationship was kept inside the driver and not exposed to the devlink
level.

If we want to use the devlink rate api to replace e.g.
ndo_set_tx_maxrate, we would need a devlink queue(id) or the like,
hence this point.

Cheer,

Paolo