From: Maxim Mikityanskiy <maxtram95@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: "Chittim, Madhu" <madhu.chittim@intel.com>,
Jiri Pirko <jiri@resnulli.us>,
netdev@vger.kernel.org, Jamal Hadi Salim <jhs@mojatatu.com>,
Cong Wang <xiyou.wangcong@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Tariq Toukan <tariqt@nvidia.com>, Gal Pressman <gal@nvidia.com>,
Saeed Mahameed <saeedm@nvidia.com>,
xuejun.zhang@intel.com, sridhar.samudrala@intel.com
Subject: Re: [PATCH net] net: sched: fix warn on htb offloaded class creation
Date: Mon, 13 Nov 2023 16:51:39 +0200 [thread overview]
Message-ID: <ZVI3-w5dsLIhqHav@mail.gmail.com> (raw)
In-Reply-To: <63b9b3f40d0476ada2972ea8f6058b3613520ba8.camel@redhat.com>
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.
> 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
>
next prev parent reply other threads:[~2023-11-13 14:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 15:36 [PATCH net] net: sched: fix warn on htb offloaded class creation Paolo Abeni
2023-10-27 13:57 ` Maxim Mikityanskiy
2023-10-29 12:01 ` Gal Pressman
2023-10-31 9:11 ` Paolo Abeni
2023-10-31 14:40 ` Maxim Mikityanskiy
2023-11-09 21:54 ` Chittim, Madhu
2023-11-10 11:07 ` Maxim Mikityanskiy
2023-11-12 8:48 ` Paolo Abeni
2023-11-13 14:51 ` Maxim Mikityanskiy [this message]
2023-11-13 15:21 ` Paolo Abeni
2023-11-15 18:51 ` Chittim, Madhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZVI3-w5dsLIhqHav@mail.gmail.com \
--to=maxtram95@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=madhu.chittim@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=sridhar.samudrala@intel.com \
--cc=tariqt@nvidia.com \
--cc=xiyou.wangcong@gmail.com \
--cc=xuejun.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.