linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rajkumar Manoharan <rmanohar@codeaurora.org>
To: Ben Greear <greearb@candelatech.com>
Cc: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>,
	ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ath10k: move mgmt descriptor limit handle under mgmt_tx
Date: Sun, 06 Mar 2016 11:56:58 +0530	[thread overview]
Message-ID: <6515868944c103e2b5bf0ed4e6f22924@codeaurora.org> (raw)
In-Reply-To: <56DBADE6.5060507@candelatech.com>

On , Ben Greear wrote:
> On 03/05/2016 08:00 PM, Rajkumar Manoharan wrote:
>> On , Ben Greear wrote:
>>> On 03/05/2016 06:10 AM, Rajkumar Manoharan wrote:
>>>> Firmware reserves few descriptors for management frames 
>>>> transmission.
>>>> In 16 MBSSID scenario, these slots will be easy exhausted due to 
>>>> frequent
>>>> probe responses. So for 10.4 based solutions, probe responses are 
>>>> limited
>>>> by a threshold (24).
>>> 
>>> Do you mean probe requests or probe responses?
>>> 
>> I meant probe responses in AP mode.
>> 
>>> A single hardware scan request with lots of ssids in it will utilize 
>>> all
>>> firmware tx management frames (which is 5, it seems).  In my testing, 
>>> the
>>> firmware would just never send probe requests for the rest of the 
>>> ssids
>>> because the firmware scan state machine logic is broken.
>>> 
>> Hmm... firmware expects both ssid and bssid list to be filled for 
>> multiple probe
>> requests. Better to try with different probe spacing time, repeat 
>> probe time and
>> probe delay and dwell time as these params change prob_req behavior in 
>> firmware.
> 
> It was easier to just fix the firmware than to hack the
> rest of the stack.
> 
I didn't mean to hack the stack :) but scan params should not be 
constant for all type
of scan requests.

>> Anyway this change is not related to scan functionality.
>> 
>>> If you really do mean responses, then it sounds like it would be 
>>> better to
>>> use the normal RX path for mgt frames in the firmware...
>>> 
>> Let me clarify. Sending probe responses in AP mode are limited by a 
>> threshold
>> for qca99x0 ("ath10k: drop probe responses when too many are queued"). 
>> This change
>> moves probe response checks under mgmt_tx from common data path.
> 
> Ok, I'll take a look at that.  I've implemented MGT frames over the 
> completely
> normal HTT data-path transport, so probably I won't hit that in my 
> systems
> anyway (there should be no internal mgt-frame limitation, except for 
> locally
> created things like probe requests during scan).  But, I could be 
> missing
> something...I'm really just getting started with 10.4...
> 
Great.. just noticed that this change needs to be rebased on top of 
Michal's recent
data path series. Let me send next version.

-Rajkumar

      reply	other threads:[~2016-03-06  6:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-05 14:10 [PATCH] ath10k: move mgmt descriptor limit handle under mgmt_tx Rajkumar Manoharan
2016-03-05 14:30 ` Ben Greear
2016-03-06  4:00   ` Rajkumar Manoharan
2016-03-06  4:11     ` Ben Greear
2016-03-06  6:26       ` Rajkumar Manoharan [this message]

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=6515868944c103e2b5bf0ed4e6f22924@codeaurora.org \
    --to=rmanohar@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rmanohar@qti.qualcomm.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;
as well as URLs for NNTP newsgroup(s).