All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Brian Norris <briannorris@chromium.org>
Cc: <linux-kernel@vger.kernel.org>,
	Amitkumar Karwar <amitkarwar@gmail.com>,
	Nishant Sarmukadam <nishants@marvell.com>,
	Ganapathi Bhat <gbhat@marvell.com>,
	Xinming Hu <huxinming820@gmail.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v2 2/2] mwifiex: add NL80211_STA_INFO_RX_BITRATE support
Date: Fri, 07 Dec 2018 12:50:25 +0200	[thread overview]
Message-ID: <87ftv9ehla.fsf@codeaurora.org> (raw)
In-Reply-To: <20181207001249.165477-2-briannorris@chromium.org> (Brian Norris's message of "Thu, 6 Dec 2018 16:12:49 -0800")

Brian Norris <briannorris@chromium.org> writes:

> Comparing the existing TX_BITRATE parsing code (in
> mwifiex_parse_htinfo()) with the RX bitrate histograms in debugfs.c, it
> appears that the rxpd_rate and rxpd_htinfo fields have the same format.
> At least, they give reasonable results when I parse them this way.
>
> So this patch adds support for RX_BITRATE to our station info dump.
>
> Along the way, I add legacy bitrate parsing into the same function,
> using the debugfs code (mwifiex_histogram_read() and
> mwifiex_adjust_data_rate()) as reference.
>
> Additionally, to satisfy the requirements of
> NL80211_STA_INFO_RX_BITRATE, I skip logging the bitrate of multicast
> packets. This shouldn't add a lot of overhead to the RX path, as there
> are already several similar 802.3 header checks in this same codepath.
> We can also bias the branch behavior to favor unicast, as that's the
> common performance-sensitive case.
>
> I'd consider this support somewhat experimental, as I have zero
> documentation from Marvell. But the existing driver code gives me good
> reason to think this is correct.
>
> I've tested this on a few different 802.11{a,b,g,n,ac} networks, and the
> reported bitrates look good to me.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> RFC: I'd appreciate it if someone from Marvell could double check my work
> here.

BTW, if we don't hear anything from Marvell I'm going to apply these
anyway.

-- 
Kalle Valo

  reply	other threads:[~2018-12-07 10:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07  0:12 [RFC PATCH v2 1/2] mwifiex: refactor mwifiex_parse_htinfo() for reuse Brian Norris
2018-12-07  0:12 ` [RFC PATCH v2 2/2] mwifiex: add NL80211_STA_INFO_RX_BITRATE support Brian Norris
2018-12-07 10:50   ` Kalle Valo [this message]
2018-12-07 11:55     ` [EXT] " Ganapathi Bhat
2018-12-13 14:55 ` [RFC PATCH v2 1/2] mwifiex: refactor mwifiex_parse_htinfo() for reuse Kalle Valo

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=87ftv9ehla.fsf@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=amitkarwar@gmail.com \
    --cc=briannorris@chromium.org \
    --cc=gbhat@marvell.com \
    --cc=huxinming820@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nishants@marvell.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.