[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <63b9b3f40d0476ada2972ea8f6058b3613520ba8.camel@redhat.com>
Date: Sun, 12 Nov 2023 09:48:19 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Maxim Mikityanskiy <maxtram95@...il.com>, "Chittim, Madhu"
<madhu.chittim@...el.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 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).
"""
> 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).
Jiri's suggested to use TC:
https://lore.kernel.org/netdev/ZOTVkXWCLY88YfjV@nanopsycho/
which IMHO makes sense as far as there is an existing interface (qdisc)
providing the required features (almost) out-of-the-box. It looks like
it's not the case.
If a non trivial configuration and/or significant implementation are
required, IMHO other options could be better...
> If you need shaping for the whole netdev, maybe HTB
> is not needed, and it's enough to attach a catchall filter with the
> police action? Or use /sys/class/net/eth0/queues/tx-*/tx_maxrate
> per-queue?
... specifically this latter one (it will require implementing in-
kernel support for 'max_rate', but should quite straight-forward).
It would be great to converge on some agreement on the way forward,
thanks!
Paolo
Powered by blists - more mailing lists