From: Simon Barber <simon@superduper.net>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] bufferbloat bug 216 could use some eyeballs badly
Date: Mon, 01 Aug 2011 12:44:42 -0700 [thread overview]
Message-ID: <4E37022A.2070705@superduper.net> (raw)
In-Reply-To: <20110801133044.GA28112@tuxdriver.com>
I did the original implementation of wireless queuing in mac80211. The
original implementation installed a special wireless root qdisc on the
interface in order to model the hardware queues correctly, and allow
leaf qdiscs to be installed. Ideally the MAC queues would also have been
moved into this qdisc. The wireless root qdisc sat on an interface that
represented the physical radio and had an 802.11 frame type. There were
one or more 802.3 format virtual interfaces that represented wireless
client or APs. The wireless qdisc on the native 802.11 interface saw
frames in 802.11 format, and hence could calculate how much airtime
would be taken transmitting the frame - this would allow development of
qdiscs to do things like share airtime rather than bandwidth. The
wireless root qdisc exposed the native hardware queues that exist in
802.11 chip sets and bypassed the normal single queue netdev interface.
This allowed the hardware queues to be fed independently.
Unfortunately the native 802.11 interface was deemed confusing to users,
and this code got pulled out of the kernel, thus preventing the qdisc
system from ever properly working when more than one virtual Ethernet
interface is used with a wireless card - such as when you run multiple
virtual APs on a wireless card, or simultaneous AP and client modes.
This concept of a special wireless root qdisc is necessary to model the
hardware queues and the MAC queues in 802.11 correctly - you're not
queuing lots of frames in the driver, rather extending the queuing
system to implement parts of the MAC.
Simon
On 08/01/2011 06:30 AM, John W. Linville wrote:
> On Mon, Aug 01, 2011 at 06:06:43AM -0600, Dave Taht wrote:
>> If anyone can spare some eyeballs for the discussion of wireless-n AMPDUs
>> and their interaction with bufferbloat, and groks TCP's behavior and/or
>> wireless's behavior, I'd appreciate some comment on:
>>
>> http://www.bufferbloat.net/issues/216
>>
>> Losing SOME appropriate packets, somewhere in the wireless stack, is
>> necessary.
>
> It seems appropriate to Cc: linux-wireless@vger.kernel.org for this...
>
next prev parent reply other threads:[~2011-08-01 18:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-01 12:06 Dave Taht
2011-08-01 13:30 ` John W. Linville
2011-08-01 19:44 ` Simon Barber [this message]
2011-08-01 20:19 [Bloat] bufferbloat bug [#216] " Dave Taht
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
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E37022A.2070705@superduper.net \
--to=simon@superduper.net \
--cc=bloat@lists.bufferbloat.net \
/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