linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	Kalle Valo <kvalo@codeaurora.org>,
	pkshih@realtek.com
Cc: Larry.Finger@lwfinger.net, yhchuang@realtek.com,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2 05/10] rtlwifi: enable mac80211 fast-tx support
Date: Wed, 17 Jan 2018 09:37:06 +0100	[thread overview]
Message-ID: <5A5F0B32.4090006@broadcom.com> (raw)
In-Reply-To: <1516141444.410.52.camel@sipsolutions.net>

On 1/16/2018 11:24 PM, Johannes Berg wrote:
> On Tue, 2018-01-16 at 21:12 +0100, Arend van Spriel wrote:
>>
>> When I saw this flying by I had the same feeling. This is clearly not
>> how it was intended although you could interpret the comments of the
>> .set_frag_threshold() callback and IEEE80211_HW_SUPPORTS_TX_FRAG.
>> However, the fragmentation threshold is a user-configurable stack
>> parameter as per the standard. This patch effectively kill that option
>> for the user although there may be RF conditions in which fragmentation
>> can help. Having the user configure a fragmentation threshold of 2346
>> also disables fragmentation and allows mac80211 to use cached fastpath.
>>
>
>          /* fast-xmit doesn't handle fragmentation at all */
>          if (local->hw.wiphy->frag_threshold != (u32)-1 &&
>              !ieee80211_hw_check(&local->hw, SUPPORTS_TX_FRAG))
>                  goto out;
>
> so internally at least it has to be -1, does 2346 really do that?
> remember, but it might well :-)

I am getting old. In my recollection the fragmentation threshold would 
be set to maximum MPDU size, which I believed to be 2346. Not sure if 
that still is true today. To be sure taken a look in the 2016 spec:

"""
dot11FragmentationThreshold OBJECT-TYPE
SYNTAX Unsigned32 (256..65535)
UNITS "octets"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the maximum size of an individually addressed
MPDU beyond which the corresponding MSDU or MMPDU is fragmented, except
when an MSDU is transmitted under an HT-immediate or HT-delayed block ack
agreement, or when an MSDU is carried in an A-MSDU, or when an MSDU or
MMPDU is carried in an A-MPDU that does not contain a VHT single MPDU.
Fields added to the MPDU by security encapsulation are not counted against
the limit specified by this attribute. An MSDU or MMPDU might be
fragmented even if it is smaller."
DEFVAL { 65535 }
::= { dot11OperationEntry 5 }
"""

Anyway, the fact remains that we should leave it up to the user to 
control the value.

Regards,
Arend

  reply	other threads:[~2018-01-17  8:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-11  7:09 [PATCH v2 00/10] rtlwifi: fix some bugs and add btcoex functions pkshih
2018-01-11  7:09 ` [PATCH v2 01/10] rtlwifi: Use mutex to replace spin_lock to protect IPS and LPS pkshih
2018-01-12 19:36   ` Larry Finger
2018-01-11  7:09 ` [PATCH v2 02/10] rtlwifi: fix scan channel 1 fail after IPS pkshih
2018-01-15 18:49   ` Larry Finger
2018-01-11  7:09 ` [PATCH v2 03/10] rtlwifi: Add sta_statistics of mac80211's op, and set filled=0 by default pkshih
2018-01-15 18:51   ` Larry Finger
2018-01-16 15:42   ` Kalle Valo
2018-01-16 22:06     ` Johannes Berg
2018-01-11  7:09 ` [PATCH v2 04/10] rtlwifi: unlink bss when un-association pkshih
2018-01-15 18:53   ` Larry Finger
2018-01-11  7:09 ` [PATCH v2 05/10] rtlwifi: enable mac80211 fast-tx support pkshih
2018-01-15 18:54   ` Larry Finger
2018-01-16 15:45   ` Kalle Valo
2018-01-16 20:12     ` Arend van Spriel
2018-01-16 22:24       ` Johannes Berg
2018-01-17  8:37         ` Arend van Spriel [this message]
2018-01-17  8:43           ` Johannes Berg
2018-01-18  9:05         ` Pkshih
2018-01-18 10:09           ` Johannes Berg
2018-01-19  1:39             ` Pkshih
2018-01-11  7:09 ` [PATCH v2 06/10] rtlwifi: Support A-MSDU in A-MPDU capability pkshih
2018-01-15 18:55   ` Larry Finger
2018-01-11  7:09 ` [PATCH v2 07/10] rtlwifi: btcoex: Add power_on_setting routine pkshih
2018-01-15 19:19   ` Larry Finger
2018-01-16  1:28     ` Pkshih
2018-01-11  7:09 ` [PATCH v2 08/10] rtlwifi: btcoex: Remove global variables from btcoex pkshih
2018-01-15 19:02   ` Larry Finger
2018-01-11  7:09 ` [PATCH v2 09/10] rtlwifi: btcoex: Add common function for qeurying BT information pkshih
2018-01-15 19:15   ` Larry Finger
2018-01-16  0:55     ` Pkshih
2018-01-16 15:52     ` Kalle Valo
2018-01-16 17:02       ` Larry Finger
2018-01-11  7:09 ` [PATCH v2 10/10] rtlwifi: btcoex: add rfe_type parameter to btcoex pkshih
2018-01-15 19:17   ` Larry Finger

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=5A5F0B32.4090006@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=johannes@sipsolutions.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.com \
    --cc=yhchuang@realtek.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).