All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Fink <billfink@mindspring.com>
To: Jesper Dangaard Brouer <hawk@diku.dk>
Cc: Patrick McHardy <kaber@trash.net>,
	jdb@comx.dk, "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 1/2]: [NET_SCHED]: Make all rate based scheduler work with TSO.
Date: Mon, 3 Sep 2007 23:34:56 -0400	[thread overview]
Message-ID: <20070903233456.0e738183.billfink@mindspring.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0709012325080.29796@ask.diku.dk>

On Sat, 1 Sep 2007, Jesper Dangaard Brouer wrote:

> On Sat, 1 Sep 2007, Patrick McHardy wrote:
> 
> > Jesper Dangaard Brouer wrote:
> >> commit 6fdc0f061be94f5e297650961360fb7a9d1cc85d
> >> Author: Jesper Dangaard Brouer <hawk@comx.dk>
> >> Date:   Thu Aug 30 17:53:42 2007 +0200
> >> 
> >> [NET_SCHED]: Make all rate based scheduler work with TSO.
> >> 
> >> Change L2T (length to time) macros, in all rate based schedulers, to
> >> call a common function qdisc_l2t() that does the rate table lookup.
> >> This function handles if the packet size lookup is larger than the
> >> rate table, which often occurs with TSO enabled.
> >
> >
> > It still won't work properly with TSO (TBF for example already drops
> > oversized packets during ->enqueue), but its a good cleanup anyway.
> 
> Then lets call it a cleanup of the L2T macros.  In the next step we will 
> fix the different schedulers, to use the ability to lookup larger sized 
> packets. (I did notice the TBF scheduler would drop oversized packets).

Hmmm.  I guess this is also why TBF doesn't seem to work with 9000 byte
jumbo frames.

[root@lang4 ~]# tc qdisc add dev eth2 root tbf rate 2gbit buffer 5000000 limit 18000
[root@lang4 ~]# tc qdisc show                                                   qdisc pfifo_fast 0: dev eth0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc tbf 8002: dev eth2 rate 2000Mbit burst 5000000b lat 4.3s

With 9000 byte jumbo frames:

[root@lang4 ~]# ./nuttcp-5.5.5 -w10m 192.168.88.14
    0.0000 MB /   5.00 sec =    0.0000 Mbps 0 %TX 0 %RX

But reducing the MSS to 1460 to emulate a standard 1500 byte Ethernet MTU:

[root@lang4 ~]# ./nuttcp-5.5.5 -M1460 -w10m 192.168.88.14
 2335.7048 MB /  10.05 sec = 1950.3419 Mbps 62 %TX 22 %RX

This is on a 2.6.20.7 kernel.

						-Bill

  reply	other threads:[~2007-09-04  3:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31 12:22 [PATCH 1/2]: [NET_SCHED]: Make all rate based scheduler work with TSO Jesper Dangaard Brouer
2007-09-01  7:09 ` Patrick McHardy
2007-09-01 21:38   ` Jesper Dangaard Brouer
2007-09-04  3:34     ` Bill Fink [this message]
2007-09-04 16:23       ` Patrick McHardy
2007-09-04 17:40         ` Bill Fink
2007-09-05  9:17           ` Jesper Dangaard Brouer
2007-09-06  3:59             ` Bill Fink

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=20070903233456.0e738183.billfink@mindspring.com \
    --to=billfink@mindspring.com \
    --cc=davem@davemloft.net \
    --cc=hawk@diku.dk \
    --cc=jdb@comx.dk \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /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.