From: Rick Jones <rick.jones2@hpe.com>
To: Michael Richardson <mcr@sandelman.ca>,
netdev@vger.kernel.org, linux-wpan@vger.kernel.org
Cc: Alexander Aring <aar@pengutronix.de>
Subject: Re: drop all fragments inside tx queue if one gets dropped
Date: Wed, 20 Apr 2016 13:45:50 -0700 [thread overview]
Message-ID: <5717EA7E.1020606@hpe.com> (raw)
In-Reply-To: <11312.1461183334@obiwan.sandelman.ca>
For the "everything old is new again" files, back in the 1990s, it was
noticed that on the likes of a netperf UDP_STREAM test on HP-UX, with
fragmentation taking place, it was possible to consume 100% of the link
bandwidth and have 0% effective throughput because the transmit queue
was kept full with IP datagram fragments which could not possibly be
reassembled (*) because one or more of the fragments of a datagram were
dropped because the transmit queue was full.
HP-UX implemented "packet trains" where all the fragments of a
fragmented datagram were presented to the driver, which then either
queued them all, or none of them.
I don't recall seeing similar poor behaviour in Linux; I would have
assumed that the intra-stack flow-control "took care" of it. Perhaps
there is something specific to wpan which precludes that?
happy benchmarking,
rick jones
next prev parent reply other threads:[~2016-04-20 20:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 9:52 drop all fragments inside tx queue if one gets dropped Alexander Aring
2016-04-20 20:15 ` Michael Richardson
2016-04-20 20:15 ` Michael Richardson
2016-04-20 20:45 ` Rick Jones [this message]
2016-04-21 17:48 ` Michael Richardson
2016-04-21 17:48 ` Michael Richardson
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=5717EA7E.1020606@hpe.com \
--to=rick.jones2@hpe.com \
--cc=aar@pengutronix.de \
--cc=linux-wpan@vger.kernel.org \
--cc=mcr@sandelman.ca \
--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.