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] [day] [month] [year] [list]
Message-ID: <54a7dd27-a612-46f1-80dd-b43e28f8e4ce@intel.com>
Date: Wed, 15 Nov 2023 10:51:38 -0800
From: "Chittim, Madhu" <madhu.chittim@...el.com>
To: Paolo Abeni <pabeni@...hat.com>, Maxim Mikityanskiy <maxtram95@...il.com>,
	Jiri Pirko <jiri@...nulli.us>
CC: <netdev@...r.kernel.org>, Jamal Hadi Salim <jhs@...atatu.com>, Cong Wang
	<xiyou.wangcong@...il.com>, "David S. Miller" <davem@...emloft.net>, "Eric
 Dumazet" <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Tariq
 Toukan <tariqt@...dia.com>, Gal Pressman <gal@...dia.com>, Saeed Mahameed
	<saeedm@...dia.com>, <xuejun.zhang@...el.com>, <sridhar.samudrala@...el.com>
Subject: Re: [PATCH net] net: sched: fix warn on htb offloaded class creation



On 11/13/2023 7:21 AM, Paolo Abeni wrote:
> On Mon, 2023-11-13 at 16:51 +0200, Maxim Mikityanskiy wrote:
>> On Sun, 12 Nov 2023 at 09:48:19 +0100, Paolo Abeni wrote:
>>> On Fri, 2023-11-10 at 13:07 +0200, Maxim Mikityanskiy wrote:
>>>> On Thu, 09 Nov 2023 at 13:54:17 -0800, Chittim, Madhu wrote:
>>>>> We would like to enable Tx rate limiting using htb offload on all the
>>>>> existing queues.
>>>>
>>>> I don't seem to understand how you see it possible with HTB.
>>>
>>> I must admit I feel sorry for not being able to join any of the
>>> upcoming conferences, but to me it looks like there is some
>>> communication gap that could be filled by in-person discussion.
>>>
>>> Specifically the above to me sounds contradictory to what you stated
>>> here:
>>>
>>> https://lore.kernel.org/netdev/ZUEQzsKiIlgtbN-S@mail.gmail.com/
>>>
>>> """
>>>> Can HTB actually configure H/W shaping on
>>>> real_num_tx_queues?
>>>
>>> It will be on real_num_tx_queues, but after it's increased to add new
>>> HTB queues. The original queues [0, N) are used for direct traffic,
>>> same as the non-offloaded HTB's direct_queue (it's not shaped).
>>> """
>>
>> Sorry if that was confusing, there is actually no contradition, let me
>> rephrase. Queues number [0, orig_real_num_tx_queues) are direct, they
>> are not shaped, they correspond to HTB's unclassified traffic. Queues
>> number [orig_real_num_tx_queues, real_num_tx_queues) correspond to HTB
>> classes and are shaped. Here orig_real_num_tx_queues is how many queues
>> the netdev had before HTB offload was attached. It's basically the
>> standard set of queues, and HTB creates a new queue per class. Let me
>> know if that helps.
>>
>>>> What is your goal?
>>>
>>> We are looking for clean interface to configure individually min/max
>>> shaping on each TX queue for a given netdev (actually virtual
>>> function).
>>
>> Have you tried tc mqprio? If you set `mode channel` and create queue
>> groups with only one queue each, you can set min_rate and max_rate for
>> each group (==queue), and it works with the existing set of queues.
> 
> mqprio does not fit well here as:
> 
> * enforce an hard limit of 16 queues imposed by uAPI
> * traffic class/queue selection depends on skb priority. That does not
> fit well if e.g. the user would rely on a 1to1 CPU to queue mapping.
> 
> It looks like any existing scheduler would need some extension to fit
> this use case.
> 
> @Jiri: when you suggested TC do you have anything specific in your
> mind?
> 
> Otherwise it looks like extending /sys/class/net/eth0/queues/tx-
> */tx_maxrate would be more straight-forward to me.

We are planning to go with this approach of extending sysfs entry to 
have tx-maxrate and use this in our iAVF driver to support per queue Tx 
rate limiting

Below is the link to our original implementation using devlink interface 
which was rejected by Jiri
https://lore.kernel.org/netdev/20230822034003.31628-1-wenjun1.wu@intel.com/

@Jiri, @Jakub, Please advise

> 
> Thanks!
> 
> Paolo
> 



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ