linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Emmanuel Grumbach <emmanuel.grumbach@intel.com>,
	linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org,
	Stephen Hemminger <stephen@networkplumber.org>,
	Dave Taht <dave.taht@gmail.com>, Jonathan Corbet <corbet@lwn.net>
Subject: Re: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing
Date: Thu, 4 Feb 2016 12:45:57 -0800	[thread overview]
Message-ID: <56B3B885.1050409@candelatech.com> (raw)
In-Reply-To: <1454616988-21901-1-git-send-email-emmanuel.grumbach@intel.com>

On 02/04/2016 12:16 PM, Emmanuel Grumbach wrote:
> As many (all?) WiFi devices, Intel WiFi devices have
> transmit queues which have 256 transmit descriptors
> each and each descriptor corresponds to an MPDU.
> This means that when it is full, the queue contains
> 256 * ~1500 bytes to be transmitted (if we don't have
> A-MSDUs). The purpose of those queues is to have enough
> packets to be ready for transmission so that when the device
> gets an opportunity to transmit (TxOP), it can take as many
> packets as the spec allows and aggregate them into one
> A-MPDU or even several A-MPDUs if we are using bursts.

I guess this is only really usable if you have exactly one
peer connected (ie, in station mode)?

Otherwise, you could have one slow peer and one fast one,
and then I suspect this would not work so well?

For reference, ath10k has around 1400 tx descriptors, though
in practice not all are usable, and in stock firmware, I'm guessing
the NIC will never be able to actually fill up it's tx descriptors
and stop traffic.  Instead, it just allows the stack to try to
TX, then drops the frame...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2016-02-04 20:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-04 20:12 [RFC] iwlwifi: pcie: transmit queue auto-sizing Emmanuel Grumbach
2016-02-04 20:16 ` [RFC RESEND] " Emmanuel Grumbach
2016-02-04 22:06   ` Dave Taht
2016-02-07 12:39     ` Grumbach, Emmanuel
2016-02-04 20:16 ` [RFC v2] " Emmanuel Grumbach
2016-02-04 20:45   ` Ben Greear [this message]
2016-02-04 20:56     ` Grumbach, Emmanuel
2016-02-04 21:14       ` Ben Greear
2016-02-05  8:44         ` Michal Kazior
2016-02-05 16:47           ` Dave Taht
2016-02-08 10:00             ` Michal Kazior
2016-02-08 10:17               ` Emmanuel Grumbach
2016-02-05 16:48           ` Ben Greear
2016-02-08 10:04           ` Emmanuel Grumbach

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=56B3B885.1050409@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=corbet@lwn.net \
    --cc=dave.taht@gmail.com \
    --cc=emmanuel.grumbach@intel.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).