netdev - Re: [PATCH net] net: sched: fix warn on htb offloaded class creation

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]

Date: Mon, 13 Nov 2023 16:51:39 +0200
From: Maxim Mikityanskiy <maxtram95@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: "Chittim, Madhu" <madhu.chittim@...el.com>,
	Jiri Pirko <jiri@...nulli.us>, 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 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
>