Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 5312c3f6 authored by Johannes Berg's avatar Johannes Berg Committed by John W. Linville
Browse files

mac80211: fix comment regarding aggregation buf_size 



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: default avatarJohannes Berg <johannes.berg@intel.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
parent 8f06ca2c

include/net/mac80211.h

+13 −2
Original line number Diff line number Diff line
@@ -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.

 *