linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>



      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).