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
prev parent 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).