From: Stephen Hemminger <shemminger@vyatta.com>
To: Patrick McHardy <kaber@trash.net>
Cc: Ryousei Takano <ryousei@gmail.com>,
Linux Netdev List <netdev@vger.kernel.org>,
takano-ryousei@aist.go.jp
Subject: Re: HTB accuracy on 10GbE
Date: Mon, 2 Nov 2009 12:53:45 -0800 [thread overview]
Message-ID: <20091102125345.3c39c42e@nehalam> (raw)
In-Reply-To: <4AEEFE2E.7090706@trash.net>
On Mon, 02 Nov 2009 16:43:42 +0100
Patrick McHardy <kaber@trash.net> wrote:
> Ryousei Takano wrote:
> > Hi Stephen and all,
> >
> > I have observed a HTB accuracy problem on the Linux kernel 2.6.30 and
> > the Myri-10G 10 GbE NIC.
> > HTB can control the transmission rate at Gigabit speed, however it can
> > not work well at 10 Gigabit speed.
> >
> > I asked Stephen this problem at Japan Linux Symposium. He mentioned a
> > HTB bug related to the timer granularity.
> > I want to know what is happen, and what should be do for fixing it.
> >
> > Any comments and suggestions will be welcome.
> >
> > For more detail, please see the following page:
> > http://code.google.com/p/pspacer/wiki/HTBon10GbE
>
> This is not an easy problem to fix. Userspace, the kernel and the
> netlink API use 32 bit for timing related values, which is too small
> to use more than microsecond resolution. All of them need to be
> converted to use bigger types, additionally some kind of compatibility
> handling to deal with old iproute versions still using microsecond
> resolution is required.
The existing API is a legacy mish-mash. The field is limited to 32 bits,
but it might be possible to use a finer scale.
Maybe if kernel advertised finer resolution through /proc/net/psched
then table could be finer grained. This would maintain compatibility
between kernel and user space. You would need to have new kernel and
new iproute to get nanosecond resolution but older combinations would
still work.
The downside is that by using nanosecond resolution the rates are upper
bounded at 4.2seconds / packet.
next prev parent reply other threads:[~2009-11-02 20:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-02 7:22 HTB accuracy on 10GbE Ryousei Takano
2009-11-02 8:17 ` Badalian Vyacheslav
2009-11-02 15:43 ` Patrick McHardy
2009-11-02 20:53 ` Stephen Hemminger [this message]
2009-11-03 7:43 ` Badalian Vyacheslav
2009-11-03 9:33 ` Jarek Poplawski
2009-11-03 10:13 ` Badalian Vyacheslav
2009-11-03 10:54 ` Jarek Poplawski
2009-11-03 11:13 ` Badalian Vyacheslav
2009-11-04 3:13 ` Ryousei Takano
2009-11-04 3:45 ` Ryousei Takano
2009-11-04 5:03 ` Eric Dumazet
2009-11-04 5:27 ` Eric Dumazet
2009-11-04 8:19 ` Ryousei Takano
2009-11-04 11:31 ` Eric Dumazet
2009-11-04 13:39 ` Jarek Poplawski
2009-11-04 16:31 ` Ryousei Takano
2009-11-04 17:03 ` Eric Dumazet
2009-11-05 7:08 ` Ryousei Takano
2009-11-05 7:10 ` Eric Dumazet
2009-11-05 10:15 ` Ryousei Takano
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=20091102125345.3c39c42e@nehalam \
--to=shemminger@vyatta.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=ryousei@gmail.com \
--cc=takano-ryousei@aist.go.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).