From: Johannes Berg <johannes@sipsolutions.net>
To: linux-wireless@vger.kernel.org
Subject: [RFC v2 22/22] mac80211: update aggregation documentation
Date: Wed, 09 Jun 2010 17:02:04 +0200 [thread overview]
Message-ID: <20100609150457.175613999@sipsolutions.net> (raw)
In-Reply-To: 20100609150142.227469359@sipsolutions.net
From: Johannes Berg <johannes.berg@intel.com>
Even before the recent changes, the documentation
for TX aggregation was somewhat out of date. Update
it and also add documentation for the RX side.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/agg-rx.c | 23 +++++++++++++++++++++++
net/mac80211/agg-tx.c | 43 +++++++++++++++++++++++++++----------------
2 files changed, 50 insertions(+), 16 deletions(-)
--- wireless-testing.orig/net/mac80211/agg-tx.c 2010-06-09 14:50:24.000000000 +0200
+++ wireless-testing/net/mac80211/agg-tx.c 2010-06-09 14:50:26.000000000 +0200
@@ -21,28 +21,39 @@
#include "wme.h"
/**
- * DOC: TX aggregation
+ * DOC: TX A-MPDU aggregation
*
* Aggregation on the TX side requires setting the hardware flag
- * %IEEE80211_HW_AMPDU_AGGREGATION as well as, if present, the @ampdu_queues
- * hardware parameter to the number of hardware AMPDU queues. If there are no
- * hardware queues then the driver will (currently) have to do all frame
- * buffering.
+ * %IEEE80211_HW_AMPDU_AGGREGATION. The driver will then be handed
+ * packets with a flag indicating A-MPDU aggregation. The driver
+ * or device is responsible for actually aggregating the frames,
+ * as well as deciding how many and which to aggregate.
*
- * When TX aggregation is started by some subsystem (usually the rate control
- * algorithm would be appropriate) by calling the
- * ieee80211_start_tx_ba_session() function, the driver will be notified via
- * its @ampdu_action function, with the %IEEE80211_AMPDU_TX_START action.
+ * When TX aggregation is started by some subsystem (usually the rate
+ * control algorithm would be appropriate) by calling the
+ * ieee80211_start_tx_ba_session() function, the driver will be
+ * notified via its @ampdu_action function, with the
+ * %IEEE80211_AMPDU_TX_START action.
*
* In response to that, the driver is later required to call the
- * ieee80211_start_tx_ba_cb() (or ieee80211_start_tx_ba_cb_irqsafe())
- * function, which will start the aggregation session.
+ * ieee80211_start_tx_ba_cb_irqsafe() function, which will really
+ * start the aggregation session after the peer has also responded.
+ * If the peer responds negatively, the session will be stopped
+ * again right away. Note that it is possible for the aggregation
+ * session to be stopped before the driver has indicated that it
+ * is done setting it up, in which case it must not indicate the
+ * setup completion.
*
- * Similarly, when the aggregation session is stopped by
- * ieee80211_stop_tx_ba_session(), the driver's @ampdu_action function will
- * be called with the action %IEEE80211_AMPDU_TX_STOP. In this case, the
- * call must not fail, and the driver must later call ieee80211_stop_tx_ba_cb()
- * (or ieee80211_stop_tx_ba_cb_irqsafe()).
+ * Also note that, since we also need to wait for a response from
+ * the peer, the driver is notified of the completion of the
+ * handshake by the %IEEE80211_AMPDU_TX_OPERATIONAL action to the
+ * @ampdu_action callback.
+ *
+ * Similarly, when the aggregation session is stopped by the peer
+ * or something calling ieee80211_stop_tx_ba_session(), the driver's
+ * @ampdu_action function will be called with the action
+ * %IEEE80211_AMPDU_TX_STOP. In this case, the call must not fail,
+ * and the driver must later call ieee80211_stop_tx_ba_cb_irqsafe().
*/
static void ieee80211_send_addba_request(struct ieee80211_sub_if_data *sdata,
--- wireless-testing.orig/net/mac80211/agg-rx.c 2010-06-09 14:50:21.000000000 +0200
+++ wireless-testing/net/mac80211/agg-rx.c 2010-06-09 14:50:26.000000000 +0200
@@ -13,6 +13,29 @@
* published by the Free Software Foundation.
*/
+/**
+ * DOC: RX A-MPDU aggregation
+ *
+ * Aggregation on the RX side requires only implementing the
+ * @ampdu_action callback that is invoked to start/stop any
+ * block-ack sessions for RX aggregation.
+ *
+ * When RX aggregation is started by the peer, the driver is
+ * notified via @ampdu_action function, with the
+ * %IEEE80211_AMPDU_RX_START action, and may reject the request
+ * in which case a negative response is sent to the peer, if it
+ * accepts it a positive response is sent.
+ *
+ * While the session is active, the device/driver are required
+ * to de-aggregate frames and pass them up one by one to mac80211,
+ * which will handle the reorder buffer.
+ *
+ * When the aggregation session is stopped again by the peer or
+ * ourselves, the driver's @ampdu_action function will be called
+ * with the action %IEEE80211_AMPDU_RX_STOP. In this case, the
+ * call must not fail.
+ */
+
#include <linux/ieee80211.h>
#include <linux/slab.h>
#include <net/mac80211.h>
prev parent reply other threads:[~2010-06-09 15:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-09 15:01 [RFC v2 00/22] aggregation locking rework v2 Johannes Berg
2010-06-09 15:01 ` [RFC v2 01/22] mac80211: simplify station/aggregation code Johannes Berg
2010-06-09 15:01 ` [RFC v2 02/22] mac80211: use common skb queue Johannes Berg
2010-06-09 15:01 ` [RFC v2 03/22] mac80211: use common work struct Johannes Berg
2010-06-09 15:01 ` [RFC v2 04/22] mac80211: use common work function Johannes Berg
2010-06-09 15:01 ` [RFC v2 05/22] mac80211: common work skb freeing Johannes Berg
2010-06-09 15:01 ` [RFC v2 06/22] mac80211: pull mgmt frame rx into rx handler Johannes Berg
2010-06-10 4:13 ` Sujith
2010-06-10 6:28 ` Johannes Berg
2010-06-10 6:35 ` Sujith
2010-06-09 15:01 ` [RFC v2 07/22] mac80211: always process blockack action from workqueue Johannes Berg
2010-06-10 4:14 ` Sujith
2010-06-10 6:25 ` Johannes Berg
2010-06-09 15:01 ` [RFC v2 08/22] mac80211: move blockack stop due to fragmentation Johannes Berg
2010-06-09 15:01 ` [RFC v2 09/22] mac80211: move aggregation callback processing Johannes Berg
2010-06-09 15:01 ` [RFC v2 10/22] mac80211: use RCU for RX aggregation Johannes Berg
2010-06-09 15:01 ` [RFC v2 11/22] mac80211: use RCU for TX aggregation Johannes Berg
2010-06-09 15:01 ` [RFC v2 12/22] mac80211: remove non-irqsafe aggregation callbacks Johannes Berg
2010-06-09 15:01 ` [RFC v2 13/22] mac80211: refcount aggregation queue stop Johannes Berg
2010-06-09 15:01 ` [RFC v2 14/22] mac80211: make TX aggregation start/stop request async Johannes Berg
2010-06-09 15:01 ` [RFC v2 15/22] mac80211: move BA session work Johannes Berg
2010-06-09 15:01 ` [RFC v2 16/22] mac80211: defer RX agg session teardown to work Johannes Berg
2010-06-09 15:01 ` [RFC v2 17/22] mac80211: fix RX aggregation timer Johannes Berg
2010-06-09 15:02 ` [RFC v2 18/22] mac80211: change RX aggregation locking Johannes Berg
2010-06-09 15:02 ` [RFC v2 19/22] mac80211: defer TX agg session teardown to work Johannes Berg
2010-06-09 15:02 ` [RFC v2 20/22] mac80211: change TX aggregation locking Johannes Berg
2010-06-09 15:02 ` [RFC v2 21/22] mac80211: allow drivers to sleep in ampdu_action Johannes Berg
2010-06-09 15:02 ` Johannes Berg [this message]
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=20100609150457.175613999@sipsolutions.net \
--to=johannes@sipsolutions.net \
--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).