From: David Lang <david@lang.hm>
To: Bob McMahon <bob.mcmahon@broadcom.com>
Cc: Dave Taht <dave.taht@gmail.com>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
BBR Development <bbr-dev@googlegroups.com>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [Make-wifi-fast] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi
Date: Tue, 22 Nov 2022 12:16:24 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.02.2211221214470.4070@nftneq.ynat.uz> (raw)
In-Reply-To: <CAHb6LvqpVGLwN7ynT9BvsawOL_q3aY2vca7bEZKtsebN9KTtwA@mail.gmail.com>
sorry, when I was saying 'the cpu', I was meaning the main one running linux,
not something that's part of the wifi chipset.
I would be very surprised if the wifi chipset is doing any packet routing, as
opposed to just sending the packets to the main processor.
Remember, the common case isn't forwarding from one wifi device to another, it's
moving between wifi devices and the wired uplink.
David Lang
On Tue, 22 Nov 2022, Bob McMahon wrote:
> An AP's radio complex may have a CPU but that doesn't mean it is the
> standard linux stack as most think of it. Many consider this as part of
> "firmware" which can be Linux, a Linux derivative or other. Also, there
> are some levels of wired/wireless forwarding plane integration done at the
> hardware level that many might be surprised by.
>
> Bob
>
> On Tue, Nov 22, 2022 at 12:03 PM David Lang <david@lang.hm> wrote:
>
>> On Tue, 22 Nov 2022, Bob McMahon via Make-wifi-fast wrote:
>>
>>> Finally, many (most?) APs are forwarding and feeding packets at at the
>>> hardware level so not sure that the linux stack matters as much for an AP
>>> based analysis, particularly when considering multi user transmissions,
>>> i.e. multiple WiFi clients are active and sharing TXOPs.
>>
>> APs forward packets within the switch at the hardware level, but the
>> radios have
>> to go through the CPU, so any wired <-> wireless needs to go through the
>> CPU,
>> and I would be incredibly surprised if the wifi chips did wireless <->
>> wireless
>> routing at the hardware level.
>>
>> David Lang
>>
>
>
next prev parent reply other threads:[~2022-11-22 20:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-22 6:04 [Bloat] " Dave Taht
2022-11-22 19:42 ` [Bloat] [bbr-dev] " Bob McMahon
2022-11-22 20:03 ` [Bloat] [Make-wifi-fast] " David Lang
2022-11-22 20:13 ` Bob McMahon
2022-11-22 20:16 ` David Lang [this message]
2022-11-22 20:28 ` Bob McMahon
2022-11-22 20:48 ` Bob McMahon
2022-11-22 20:10 ` [Bloat] " Neal Cardwell
2022-11-22 20:53 ` Toke Høiland-Jørgensen
2022-11-22 21:00 ` Bob McMahon
2022-11-23 13:50 ` Toke Høiland-Jørgensen
2022-11-23 20:36 ` Bob McMahon
[not found] ` <003d01d8ffc5$2ace1a20$806a4e60$@umt.edu.pk>
2022-11-24 16:23 ` 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=alpine.DEB.2.02.2211221214470.4070@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=bbr-dev@googlegroups.com \
--cc=bloat@lists.bufferbloat.net \
--cc=bob.mcmahon@broadcom.com \
--cc=dave.taht@gmail.com \
--cc=make-wifi-fast@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