netdev - Re: tbf/htb qdisc limitations

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:	Thu, 14 Oct 2010 08:09:39 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Bill Fink <billfink@...dspring.com>
Cc:	Rick Jones <rick.jones2@...com>,
	Steven Brudenell <steven.brudenell@...il.com>,
	netdev@...r.kernel.org
Subject: Re: tbf/htb qdisc limitations

On Thu, Oct 14, 2010 at 03:13:54AM -0400, Bill Fink wrote:
> On Thu, 14 Oct, Jarek Poplawski wrote:
> 
> > On Wed, Oct 13, 2010 at 11:36:53PM -0400, Bill Fink wrote:
> > > On Wed, 13 Oct 2010, Jarek Poplawski wrote:
> > > 
> > > > On Tue, Oct 12, 2010 at 03:17:18PM -0700, Rick Jones wrote:
> > > > >>> my burst problem is the only semi-legitimate motivation i can think
> > > > >>> of. the only other possible motivations i can imagine are setting
> > > > >>> "limit" to buffer more than 4GB of packets and setting "rate" to
> > > > >>> something more than 32 gigabit; both of these seem kind of dubious. is
> > > > >>> there something else you had in mind?
> > > > >>
> > > > >>
> > > > >> No, mainly 10 gigabit rates and additionally 64-bit stats.
> > > > >
> > > > > Any issue for bonded 10 GbE interfaces?  Now that the IEEE have ratified 
> > > > > (June) how far out are 40 GbE interfaces?  Or 100 GbE for that matter.
> > > > 
> > > > Alas packet schedulers using rate tables are still around 1G. Above 2G
> > > > they get less and less accurate, so hfsc is recommended.
> > > 
> > > I was just trying to do an 8 Gbps rate limit on a 10-GigE path,
> > > and couldn't get it to work with either htb or tbf.  Are you
> > > saying this currently isn't possible?
> > 
> > Let's start from reminding that no precise packet scheduling should be
> > expected with gso/tso etc. turned on. I don't know current hardware
> > limits for such a non-gso traffic, but for 8 Gbit rate htb or tbf
> > would definitely have wrong rate tables (overflowed values) for packet
> > sizes below 1500 bytes.
> 
> TSO/GSO was disabled and was using 9000-byte jumbo frames
> (and specified mtu 9000 to tc command).
> 
> Here was one attempt I made using tbf:
> 
> tc qdisc add dev eth2 root handle 1: prio
> tc qdisc add dev eth2 parent 1:1 handle 10: tbf rate 8900mbit buffer 1112500 limit 10000 mtu 9000
> tc filter add dev eth2 protocol ip parent 1: prio 1 u32 match ip dst 192.168.1.23 flowid 10:1
> 
> I tried many variations of the above, all without success.

The main problem are smaller packets. If you had (almost) only 9000b
frames this probably could work. But smaller packets (I don't remember
exact limits) with wrong rate table values might go almost unaccounted.

> > > Or are you saying to use
> > > this hfsc mechanism, which there doesn't seem to be a man page
> > > for?
> > 
> > There was a try:
> > http://lists.openwall.net/netdev/2009/02/26/138
> 
> Thanks for the pointer.  I will check it out later in detail,
> but I'm already having difficulty with deciding if I have the
> tc commands right for tbf and htb, and hfsc looks even more
> involved.

I don't know much about hfsc either, but it seems, with simplest
configs (second slope only) it shouldn't be much different from htb
or tbf.

Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html