Subject: Re: tbf/htb qdisc limitations

From: Bill Fink <[email-masked]>
Date: Thu, 14 Oct 2010 03:13:54 -0400

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.

> > 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.

					-Bill