From: Bill Fink <billfink@mindspring.com>
To: Jarek Poplawski <jarkao2@gmail.com>
Cc: Rick Jones <rick.jones2@hp.com>,
Steven Brudenell <steven.brudenell@gmail.com>,
netdev@vger.kernel.org
Subject: Re: tbf/htb qdisc limitations
Date: Thu, 14 Oct 2010 03:13:54 -0400 [thread overview]
Message-ID: <20101014031354.e172d737.billfink@mindspring.com> (raw)
In-Reply-To: <20101014064404.GA6219@ff.dom.local>
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
next prev parent reply other threads:[~2010-10-14 7:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-08 20:58 tbf/htb qdisc limitations Steven Brudenell
2010-10-10 11:23 ` Jarek Poplawski
2010-10-11 22:27 ` Steven Brudenell
2010-10-12 10:10 ` Jarek Poplawski
2010-10-12 19:31 ` Steven Brudenell
2010-10-12 21:59 ` Jarek Poplawski
2010-10-12 22:17 ` Rick Jones
2010-10-13 6:26 ` Jarek Poplawski
2010-10-14 3:36 ` Bill Fink
2010-10-14 4:01 ` Eric Dumazet
2010-10-14 6:34 ` Bill Fink
2010-10-14 6:44 ` Jarek Poplawski
2010-10-14 7:13 ` Bill Fink [this message]
2010-10-14 8:09 ` Jarek Poplawski
2010-10-14 8:50 ` Jarek Poplawski
2010-10-15 6:37 ` Bill Fink
2010-10-15 6:44 ` Eric Dumazet
2010-10-15 21:37 ` Bill Fink
2010-10-15 22:05 ` Jarek Poplawski
2010-10-16 4:51 ` Bill Fink
2010-10-16 20:58 ` Jarek Poplawski
2010-10-17 1:24 ` Bill Fink
2010-10-17 20:36 ` Jarek Poplawski
2010-10-19 7:37 ` Bill Fink
2010-10-20 11:06 ` Jarek Poplawski
2010-10-27 4:51 ` Bill Fink
2010-10-27 9:48 ` Jarek Poplawski
2010-10-15 8:18 ` Jarek Poplawski
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=20101014031354.e172d737.billfink@mindspring.com \
--to=billfink@mindspring.com \
--cc=jarkao2@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
--cc=steven.brudenell@gmail.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.