From: Eric Dumazet <eric.dumazet@gmail.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: netdev@vger.kernel.org, Stephen Hemminger <shemminger@vyatta.com>
Subject: Re: [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior
Date: Thu, 01 Dec 2011 10:01:48 +0100 [thread overview]
Message-ID: <1322730108.2335.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> (raw)
In-Reply-To: <cfd2e2c26063da002d8afe76991ff0c1@localhost>
Le jeudi 01 décembre 2011 à 09:25 +0100, Hagen Paul Pfeifer a écrit :
> On Thu, 01 Dec 2011 04:30:25 +0100, Eric Dumazet wrote:
>
> > Thats a multiply instead of a divide. On many cpus thats a lot faster.
> >
> > Think about a super packet (TSO) of 65000 bytes and cell_size=64
>
> I've never imagined that I am going to say the following: you are wrong,
> Eric! (ok, maybe you are right ;-)
>
> TSO and Netem is a no-go. With netem you are strongly advised to disable
> offloading. I mean TSO will result in _one_ delay of several minutes,
> followed by a burst of packets. Instead of packets spaced by several
> seconds (with the rate of 1000byte/s) - which is what you wan't.
>
> To sum up: skb->len is _never_ larger as the MTU for (normal, correct)
> network emulation setups with netem. This was the assumption why I
> preferred the iterative solution over the div/mod solution.
>
> Did I miss something?
>
Yes :)
I want to be able to use netem on a 10Gigabit link, and simulate a 5ms
delay. I already will hit the shared qdisc bottleneck, dont force me to
use small packets !
We did cleanups in net/sched to properly handle large packets as well.
(SFQ for example is OK)
Really, reciprocal divide is the way to go, its faster anyway on modern
cpus than your loop.
next prev parent reply other threads:[~2011-12-01 9:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-30 22:20 [PATCH v3 net-next 1/2] netem: rate extension Hagen Paul Pfeifer
2011-11-30 22:20 ` [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior Hagen Paul Pfeifer
2011-12-01 3:30 ` Eric Dumazet
2011-12-01 8:25 ` Hagen Paul Pfeifer
2011-12-01 9:01 ` Eric Dumazet [this message]
2011-12-01 9:32 ` [PATCH net-next] netem: fix build error on 32bit arches Eric Dumazet
2011-12-01 9:46 ` Hagen Paul Pfeifer
2011-12-01 11:04 ` David Laight
2011-12-01 11:19 ` Eric Dumazet
2011-12-01 17:46 ` David Miller
2011-12-01 9:36 ` [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior Hagen Paul Pfeifer
2011-12-01 16:24 ` Stephen Hemminger
2011-12-01 16:38 ` David Laight
2011-12-01 16:57 ` Stephen Hemminger
2011-12-01 18:25 ` Rick Jones
2011-12-01 4:19 ` [PATCH v3 net-next 1/2] netem: rate extension David Miller
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=1322730108.2335.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC \
--to=eric.dumazet@gmail.com \
--cc=hagen@jauu.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox