linux-kernel - Re: [EXTERNAL] Re: [PATCH v2 2/3] net: mana: Add sched HTB offload support

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: <20250423145723.7ff12e1a@kernel.org>
Date: Wed, 23 Apr 2025 14:57:23 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Haiyang Zhang <haiyangz@...rosoft.com>
Cc: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>, KY Srinivasan
 <kys@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>, Dexuan Cui
 <decui@...rosoft.com>, "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
 "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
 <edumazet@...gle.com>, "pabeni@...hat.com" <pabeni@...hat.com>, Long Li
 <longli@...rosoft.com>, Konstantin Taranov <kotaranov@...rosoft.com>,
 "horms@...nel.org" <horms@...nel.org>, "mhklinux@...look.com"
 <mhklinux@...look.com>, "pasha.tatashin@...een.com"
 <pasha.tatashin@...een.com>, "kent.overstreet@...ux.dev"
 <kent.overstreet@...ux.dev>, "brett.creeley@....com"
 <brett.creeley@....com>, "schakrabarti@...ux.microsoft.com"
 <schakrabarti@...ux.microsoft.com>, "shradhagupta@...ux.microsoft.com"
 <shradhagupta@...ux.microsoft.com>, "ssengar@...ux.microsoft.com"
 <ssengar@...ux.microsoft.com>, "rosenp@...il.com" <rosenp@...il.com>, Paul
 Rosswurm <paulros@...rosoft.com>, "linux-hyperv@...r.kernel.org"
 <linux-hyperv@...r.kernel.org>, "netdev@...r.kernel.org"
 <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>
Subject: Re: [EXTERNAL] Re: [PATCH v2 2/3] net: mana: Add sched HTB offload
 support

On Wed, 23 Apr 2025 15:27:16 +0000 Haiyang Zhang wrote:
> > > We selected tc-htb for our current use case because we plan to support
> > > multiple speed classes in the future.  
> > 
> > Which net-shapers also support.  
> 
> Thanks for pointing that out...
> But for easier usage with existing tc tool for customers, can we still
> use tc-htb offload? Does using tc-htb offload for speed clamping break
> any coding convention or API specs?

The only spec here is that the offloaded version is supposed to look
like the non-offloaded one. I really don't see how you can claim that
static single class HTB is a accurate offload of HTB.