netdev - Re: [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: <5aed9b87-28f8-f0b0-67c4-346e1d8f762c@intel.com>
Date: Mon, 28 Aug 2023 15:46:02 -0700
From: "Zhang, Xuejun" <xuejun.zhang@...el.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: Jakub Kicinski <kuba@...nel.org>, Wenjun Wu <wenjun1.wu@...el.com>,
	<intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
	<madhu.chittim@...el.com>, <qi.z.zhang@...el.com>,
	<anthony.l.nguyen@...el.com>
Subject: Re: [PATCH iwl-next v4 0/5] iavf: Add devlink and devlink rate
 support'


On 8/24/2023 12:04 AM, Jiri Pirko wrote:
> Wed, Aug 23, 2023 at 09:13:34PM CEST, xuejun.zhang@...el.com wrote:
>> On 8/22/2023 8:34 AM, Jiri Pirko wrote:
>>> Tue, Aug 22, 2023 at 05:12:55PM CEST,kuba@...nel.org  wrote:
>>>> On Tue, 22 Aug 2023 08:12:28 +0200 Jiri Pirko wrote:
>>>>> NACK! Port function is there to configure the VF/SF from the eswitch
>>>>> side. Yet you use it for the configureation of the actual VF, which is
>>>>> clear misuse. Please don't
>>>> Stating where they are supposed to configure the rate would be helpful.
>>> TC?
>> Our implementation is an extension to this commit 42c2eb6b1f43 ice: Implement
>> devlink-rate API).
>>
>> We are setting the Tx max & share rates of individual queues in a VF using
>> the devlink rate API.
>>
>> Here we are using DEVLINK_PORT_FLAVOUR_VIRTUAL as the attribute for the port
>> to distinguish it from being eswitch.
> I understand, that is a wrong object. So again, you should use
> "function" subobject of devlink port to configure "the other side of the
> wire", that means the function related to a eswitch port. Here, you are
> doing it for the VF directly, which is wrong. If you need some rate
> limiting to be configured on an actual VF, use what you use for any
> other nic. Offload TC.
Thanks for detailed explanation and suggestions. Sorry for late reply as 
it took a bit longer to understand options.

As sysfs has similar rate configuration on per queue basis with 
tx_maxrate, is it a viable option for our use case (i.e allow user to 
configure tx rate for each allocated queue in a VF).

Pls aslo see If adding tx_minrate to sysfs tx queue entry is feasible on 
the current framework.