From patchwork Fri Aug 7 14:23:43 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Berg X-Patchwork-Id: 39932 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n77ENos4013125 for ; Fri, 7 Aug 2009 14:23:50 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757551AbZHGOXr (ORCPT ); Fri, 7 Aug 2009 10:23:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757521AbZHGOXr (ORCPT ); Fri, 7 Aug 2009 10:23:47 -0400 Received: from xc.sipsolutions.net ([83.246.72.84]:56323 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757515AbZHGOXr (ORCPT ); Fri, 7 Aug 2009 10:23:47 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MZQMC-0004iv-Uu; Fri, 07 Aug 2009 16:23:45 +0200 Subject: [PATCH] mac80211: explain TX retry and status From: Johannes Berg To: John Linville Cc: nbd , linux-wireless Date: Fri, 07 Aug 2009 16:23:43 +0200 Message-Id: <1249655023.7194.4.camel@johannes.local> Mime-Version: 1.0 X-Mailer: Evolution 2.27.5 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Add some more documentation including an example so that it's clearer what should be done for TX retries. Signed-off-by: Johannes Berg --- include/net/mac80211.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- wireless-testing.orig/include/net/mac80211.h 2009-08-07 16:18:15.000000000 +0200 +++ wireless-testing/include/net/mac80211.h 2009-08-07 16:22:21.000000000 +0200 @@ -338,6 +338,21 @@ enum mac80211_rate_control_flags { * * When used for transmit status reporting, the driver should * always report the rate along with the flags it used. + * + * &struct ieee80211_tx_info contains an array of these structs + * in the control information, and it will be filled by the rate + * control algorithm according to what should be sent. For example, + * if this array contains, in the format { , } the + * information + * { 3, 2 }, { 2, 2 }, { 1, 4 }, { -1, 0 }, { -1, 0 } + * then this means that the frame should be transmitted + * up to twice at rate 3, up to twice at rate 2, and up to four + * times at rate 1 if it doesn't get acknowledged. Say it gets + * acknowledged by the peer after the fifth attempt, the status + * information should then contain + * { 3, 2 }, { 2, 2 }, { 1, 1 }, { -1, 0 } ... + * since it was transmitted twice at rate 3, twice at rate 2 + * and once at rate 1 after which we received an acknowledgement. */ struct ieee80211_tx_rate { s8 idx;