Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

mac80211: fix comment regarding aggregation buf_size

Browse source 
The description for buf_size was misleading and
just said you couldn't TX larger aggregates, but
of course you can't TX aggregates in a way that
would exceed the window either, which is possible
even if the aggregates are shorter than that.

Expand the description, thanks to Emmanuel for
explaining this to me.

Cc: Emmanuel Grumbach <egrumbach@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This commit is contained in:
Johannes Berg 2011-04-01 13:52:34 +02:00 committed by John W. Linville
parent 8f06ca2c83
commit 5312c3f60b
1 changed files with 13 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
include/net/mac80211.h
View file

@ -1753,8 +1753,19 @@ enum ieee80211_ampdu_mlme_action {
* that TX/RX_STOP can pass NULL for this parameter.
* The @buf_size parameter is only valid when the action is set to
* %IEEE80211_AMPDU_TX_OPERATIONAL and indicates the peer's reorder
* buffer size (number of subframes) for this session -- aggregates
* containing more subframes than this may not be transmitted to the peer.
* buffer size (number of subframes) for this session -- the driver
* may neither send aggregates containing more subframes than this
* nor send aggregates in a way that lost frames would exceed the
* buffer size. If just limiting the aggregate size, this would be
* possible with a buf_size of 8:
* - TX: 1.....7
* - RX: 2....7 (lost frame #1)
* - TX: 8..1...
* which is invalid since #1 was now re-transmitted well past the
* buffer size of 8. Correct ways to retransmit #1 would be:
* - TX: 1 or 18 or 81
* Even "189" would be wrong since 1 could be lost again.
*
* Returns a negative error code on failure.
* The callback can sleep.
*