linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anilkumar Kolli <akolli@codeaurora.org>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: Jouni Malinen <jouni@codeaurora.org>,
	ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
	akolli=codeaurora.org@codeaurora.org
Subject: Re: [PATCH 1/3] ath11k: add htt cmd to enable full monitor mode
Date: Mon, 04 Oct 2021 09:53:18 +0530	[thread overview]
Message-ID: <88d088e700888eb9c97eb5c2984af65f@codeaurora.org> (raw)
In-Reply-To: <190d91d77d24c708291111710d4667b0@codeaurora.org>

On 2021-09-30 12:17, Anilkumar Kolli wrote:
> On 2021-09-28 12:26, Kalle Valo wrote:
>> akolli@codeaurora.org writes:
>> 
>>> On 2021-09-24 17:12, Kalle Valo wrote:
>>>> Jouni Malinen <jouni@codeaurora.org> writes:
>>>> 
>>>>> From: Anilkumar Kolli <akolli@codeaurora.org>
>>>>> 
>>>>> Add a new hw_param full_monitor_mode to enable full monitor support
>>>>> for
>>>>> QCN9074. HTT_H2T_MSG_TYPE_RX_FULL_MONITOR_MODE cmd is sent to the
>>>>> firmware to enable the full monitor mode.
>>>> 
>>>> Nowhere it's explained what "full monitor mode" means from an user's
>>>> point of view. Can someone give a high level summary what advantages
>>>> this feature has? For example, more frames delivered to user space 
>>>> or
>>>> what?
>>> 
>>> Yes, more frames delivered with full monitor mode. The advantage with
>>> full monitor mode is, hardware has status buffers available for all
>>> the MPDUs in mon_dst_ring. Both status buffer and MPDUs from
>>> mon_dst_ring is used to build the frame.
>> 
>> Users, and developers outside of the wireless domain, have no clue 
>> what
>> "MPDUs in mon_dst_ring" means, just as an example. Can you give a 
>> higher
>> level summary of this feature and what benefit it brings, please? I'll
>> then add that to the commit log.
>> 
>> For example, what kind of frames are we now able to deliver to the 
>> user
>> space (which we before couldn't) and are there still some types of
>> frames which we are not delivering?
>> 
>> In other words, instead of technical low level jargon I'm looking for 
>> a
>> summary in plain english which is understandable by everyone.
> 
> Full monitor mode is hardware enhancement for QCN9074. With this more
> frames are delivered to mac80211.
> 
> In earlier hardware like IPQ8074, on each interrupt, reap complete
> monitor status ring.
> For each PPDU_DONE status, reap monitor destination ring, this needs
> more processing on driver.
> 
> With full monitor, on Interrupt, there is no need to reap the complete
> monitor status ring.
> Instead only one PPDU is reap from monitor destination ring and
> corresponding PPDU status is reaped.
> 
> In older approach, in noisy environments status buffers are missing
> for few PPDU, even in that case
> Host reaps monitor destination ring, which is not needed and these
> frames are dropped.
> 

Radiotap header is constructed from monitor status buffer tlvs. Since 
there is
no update of status buffer for few PPDU, complete 80211 frame is not 
formed and
is dropped in ath11k.

> In full monitor mode, for all MPDUs in a PPDU, status is guaranteed,
> this is achieved in hardware using lock-stepping.
> So more frames delivered to mac80211 and more fames seen in sniffer. "
> 


- Anil.

  reply	other threads:[~2021-10-04  4:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21 17:19 [PATCH 0/3] ath11k: add full monitor mode support for QCN9074 Jouni Malinen
2021-07-21 17:19 ` [PATCH 1/3] ath11k: add htt cmd to enable full monitor mode Jouni Malinen
2021-09-24 11:42   ` Kalle Valo
2021-09-27  4:19     ` akolli
2021-09-28  6:56       ` Kalle Valo
2021-09-30  6:47         ` Anilkumar Kolli
2021-10-04  4:23           ` Anilkumar Kolli [this message]
2021-09-24 13:52   ` Kalle Valo
2021-09-27  4:31     ` Anilkumar Kolli
2021-07-21 17:19 ` [PATCH 2/3] ath11k: add software monitor ring descriptor for full monitor Jouni Malinen
2021-07-21 17:19 ` [PATCH 3/3] ath11k: process full monitor mode rx support Jouni Malinen
2021-11-12  7:52   ` Kalle Valo
2021-12-08 13:13     ` Anilkumar Kolli

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=88d088e700888eb9c97eb5c2984af65f@codeaurora.org \
    --to=akolli@codeaurora.org \
    --cc=akolli=codeaurora.org@codeaurora.org \
    --cc=ath11k@lists.infradead.org \
    --cc=jouni@codeaurora.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.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).