[<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