mac80211: add private driver flags and ampdu length to tx info

PATCH In review Felix Fietkau 2 participants 7 messages Nov 14, 2009 – Nov 15, 2009

Subsystems (2)

mac80211 Qualcomm Atheros ATH9K wireless driver

lore

Share & tools

lore

Felix Fietkau

author

2009-11-14 16:06 UTC #0 lore raw

PATCH 1/2 mac80211: add private driver flags and ampdu length to tx info

Some drivers may want to store a few flags of their own in the tx info. Also it is useful for 11n rate control to know the total number of aggregated frames in an AMPDU, not just the ones that were acked.

Signed-off-by Felix Fietkau <[email protected]>

---

include/net/mac80211.h +9 -5

@@ -386,14 +386,17 @@ struct ieee80211_tx_rate {
  * @flags: transmit info flags, defined above
  * @band: the band to transmit on (use for checking for races)
  * @antenna_sel_tx: antenna to use, 0 for automatic diversity
+ * @driver_flags: flags for internal driver use
  * @pad: padding, ignore
  * @control: union for control data
  * @status: union for status data
  * @driver_data: array of driver_data pointers
- * @ampdu_ack_len: number of aggregated frames.
- * 	relevant only if IEEE80211_TX_STATUS_AMPDU was set.
+ * @ampdu_ack_len: number of acked aggregated frames.
+ * 	relevant only if ieee80211_tx_status_ampdu was set.
  * @ampdu_ack_map: block ack bit map for the aggregation.
  * 	relevant only if IEEE80211_TX_STATUS_AMPDU was set.
+ * @ampdu_len: number of aggregated frames.
+ * 	relevant only if ieee80211_tx_status_ampdu was set.
  * @ack_signal: signal strength of the ACK frame
  */
 struct ieee80211_tx_info {

@@ -403,8 +406,8 @@ struct ieee80211_tx_info {
 
 	u8 antenna_sel_tx;
 
-	/* 2 byte hole */
-	u8 pad[2];
+	u8 driver_flags;
+	u8 pad;
 
 	union {
 		struct {

@@ -428,7 +431,8 @@ struct ieee80211_tx_info {
 			u8 ampdu_ack_len;
 			u64 ampdu_ack_map;
 			int ack_signal;
-			/* 8 bytes free */
+			u8 ampdu_len;
+			/* 7 bytes free */
 		} status;
 		struct {
 			struct ieee80211_tx_rate driver_rates[

Felix Fietkau

author

2009-11-14 16:08 UTC #1 lore raw

PATCH 2/2 ath9k: get rid of tx_info_priv

This patch removes the need for separately allocated private tx info data in ath9k and brings the driver one small step closer to using the mac80211 rate control API properly.

Signed-off-by Felix Fietkau <[email protected]>

---

drivers/net/wireless/ath/ath9k/common.h +1 -0

@@ -81,6 +81,7 @@ struct ath_buf {
 	u16 bf_flags;
 	struct ath_buf_state bf_state;
 	dma_addr_t bf_dmacontext;
+	struct ath_wiphy *aphy;
 };
 
 struct ath_atx_tid {

drivers/net/wireless/ath/ath9k/rc.h +6 ~~-12~~

@@ -167,24 +167,18 @@ struct ath_rate_priv {
 	struct ath_rate_softc *asc;
 };
 
+#define ATH_TX_INFO_FRAME_TYPE_INTERNAL	(1 << 0)
+#define ATH_TX_INFO_FRAME_TYPE_PAUSE	(1 << 1)
+#define ATH_TX_INFO_UPDATE_RC		(1 << 2)
+#define ATH_TX_INFO_XRETRY		(1 << 3)
+#define ATH_TX_INFO_UNDERRUN		(1 << 4)
+
 enum ath9k_internal_frame_type {
 	ATH9K_NOT_INTERNAL,
 	ATH9K_INT_PAUSE,
 	ATH9K_INT_UNPAUSE
 };
 
-struct ath_tx_info_priv {
-	struct ath_wiphy *aphy;
-	struct ath_tx_status tx;
-	int n_frames;
-	int n_bad_frames;
-	bool update_rc;
-	enum ath9k_internal_frame_type frame_type;
-};
-
-#define ATH_TX_INFO_PRIV(tx_info) \
-	((struct ath_tx_info_priv *)((tx_info)->rate_driver_data[0]))
-
 void ath_rate_attach(struct ath_softc *sc);
 u8 ath_rate_findrateix(struct ath_softc *sc, u8 dot11_rate);
 int ath_rate_control_register(void);

drivers/net/wireless/ath/ath9k/virtual.c +2 -7

@@ -338,13 +338,11 @@ void ath9k_wiphy_chan_work(struct work_s
 void ath9k_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
 {
 	struct ath_wiphy *aphy = hw->priv;
-	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
-	struct ath_tx_info_priv *tx_info_priv = ATH_TX_INFO_PRIV(tx_info);
 
-	if (tx_info_priv && tx_info_priv->frame_type == ATH9K_INT_PAUSE &&
+	if ((tx_info->driver_flags & ATH_TX_INFO_FRAME_TYPE_PAUSE) &&
 	    aphy->state == ATH_WIPHY_PAUSING) {
-		if (!(info->flags & IEEE80211_TX_STAT_ACK)) {
+		if (!(tx_info->flags & IEEE80211_TX_STAT_ACK)) {
 			printk(KERN_DEBUG "ath9k: %s: no ACK for pause "
 			       "frame\n", wiphy_name(hw->wiphy));
 			/*

@@ -363,9 +361,6 @@ void ath9k_tx_status(struct ieee80211_hw
 		}
 	}
 
-	kfree(tx_info_priv);
-	tx_info->rate_driver_data[0] = NULL;
-
 	dev_kfree_skb(skb);
 }

drivers/net/wireless/ath/ath9k/xmit.c +32 ~~-38~~

165 lines not on this page · raw message

drivers/net/wireless/ath/ath9k/debug.c +7 -4

@@ -257,14 +257,17 @@ static const struct file_operations fops
 
 void ath_debug_stat_rc(struct ath_softc *sc, struct sk_buff *skb)
 {
-	struct ath_tx_info_priv *tx_info_priv = NULL;
 	struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
 	struct ieee80211_tx_rate *rates = tx_info->status.rates;
-	int final_ts_idx, idx;
+	int final_ts_idx = 0, idx, i;
 	struct ath_rc_stats *stats;
 
-	tx_info_priv = ATH_TX_INFO_PRIV(tx_info);
-	final_ts_idx = tx_info_priv->tx.ts_rateindex;
+	for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
+		if (!rates[i].count)
+			break;
+
+		final_ts_idx = i;
+	}
 	idx = rates[final_ts_idx].idx;
 	stats = &sc->debug.stats.rcstats[idx];
 	stats->success++;

drivers/net/wireless/ath/ath9k/rc.c +35 ~~-36~~

171 lines not on this page · raw message

Johannes Berg

maintainer

2009-11-15 14:01 UTC #2 lore raw

In reply to Felix Fietkau

Quoted 4 lines · Felix Fietkau

- * @ampdu_ack_len: number of aggregated frames.
- * relevant only if IEEE80211_TX_STATUS_AMPDU was set.
+ * @ampdu_ack_len: number of acked aggregated frames.
+ * relevant only if ieee80211_tx_status_ampdu was set.

why lowercase that?

include/net/mac80211.h struct ieee80211_tx_info { · line 410

Quoted 4 lines

include/net/mac80211.h +2 -2

-	/* 2 byte hole */
-	u8 pad[2];
+	u8 driver_flags;
+	u8 pad;

The ampdu_len seems ok, but I'm still not convinced this is right. Drivers _should_ have enough space in the driver parts of this struct, and not need flags here. I realise that you do need that because of the RC and other internal things, but maybe you could simply use "pad[0]" for that so not to encourage others to start doing this too?

johannes

Felix Fietkau

author

2009-11-15 14:19 UTC #3 lore raw

Quoted 8 lines · Johannes Berg

Quoted 4 lines · Felix Fietkau
- * @ampdu_ack_len: number of aggregated frames.
- * relevant only if IEEE80211_TX_STATUS_AMPDU was set.
+ * @ampdu_ack_len: number of acked aggregated frames.
+ * relevant only if ieee80211_tx_status_ampdu was set.
why lowercase that?

Sorry, late night vim accident. I'll resend...

Quoted 10 lines

include/net/mac80211.h struct ieee80211_tx_info { · line 410
Quoted 4 lines
include/net/mac80211.h +2 -2
-	/* 2 byte hole */
-	u8 pad[2];
+	u8 driver_flags;
+	u8 pad;
The ampdu_len seems ok, but I'm still not convinced this is right. Drivers _should_ have enough space in the driver parts of this struct, and not need flags here. I realise that you do need that because of the RC and other internal things, but maybe you could simply use "pad[0]" for that so not to encourage others to start doing this too?

If you prefer it using the padding directly, I can change it to that too. I don't mind as long as I have space to put that stuff into and don't need to use rate_driver_data.

- Felix

Johannes Berg

maintainer

2009-11-15 14:27 UTC #4 lore raw

Quoted 5 lines · Felix Fietkau

Quoted 4 lines
Quoted 2 lines
+ * @ampdu_ack_len: number of acked aggregated frames.
+ * relevant only if ieee80211_tx_status_ampdu was set.
why lowercase that?
Sorry, late night vim accident. I'll resend...

same a few lines down too

Quoted 11 lines

Quoted 10 lines
include/net/mac80211.h struct ieee80211_tx_info { · line 410
Quoted 4 lines
include/net/mac80211.h +2 -2
-	/* 2 byte hole */
-	u8 pad[2];
+	u8 driver_flags;
+	u8 pad;
The ampdu_len seems ok, but I'm still not convinced this is right. Drivers _should_ have enough space in the driver parts of this struct, and not need flags here. I realise that you do need that because of the RC and other internal things, but maybe you could simply use "pad[0]" for that so not to encourage others to start doing this too?

Quoted 3 lines

If you prefer it using the padding directly, I can change it to that too. I don't mind as long as I have space to put that stuff into and don't need to use rate_driver_data.

I can't really decide. On the one hand, using pad seems bad, but on the other hand I'm still hoping this will just be temporary (for some value thereof). But in that case I fear that we might find somebody else started using the new field and we need to fix that driver too then...

Thoughts?

johannes

Felix Fietkau

author

2009-11-15 14:36 UTC #5 lore raw

Quoted 21 lines · Johannes Berg

Quoted 5 lines · Felix Fietkau
Quoted 4 lines
Quoted 2 lines
+ * @ampdu_ack_len: number of acked aggregated frames.
+ * relevant only if ieee80211_tx_status_ampdu was set.
why lowercase that?
Sorry, late night vim accident. I'll resend...
same a few lines down too
Quoted 10 lines
Quoted 10 lines
include/net/mac80211.h struct ieee80211_tx_info { · line 410
Quoted 4 lines
include/net/mac80211.h +2 -2
-	/* 2 byte hole */
-	u8 pad[2];
+	u8 driver_flags;
+	u8 pad;
The ampdu_len seems ok, but I'm still not convinced this is right. Drivers _should_ have enough space in the driver parts of this struct, and not need flags here. I realise that you do need that because of the RC and other internal things, but maybe you could simply use "pad[0]" for that so not to encourage others to start doing this too?

Quoted 8 lines

Quoted 3 lines
If you prefer it using the padding directly, I can change it to that too. I don't mind as long as I have space to put that stuff into and don't need to use rate_driver_data.
I can't really decide. On the one hand, using pad seems bad, but on the other hand I'm still hoping this will just be temporary (for some value thereof). But in that case I fear that we might find somebody else started using the new field and we need to fix that driver too then...

There are only two parts that need this. The first one is the ath9k virtual wiphy type, no idea when that will change.
The second one is for passing stuff to rate control. That one will go away once we replace ath9k's rc.c ;)
It might just be temporary...

- Felix

Johannes Berg

maintainer

2009-11-15 15:00 UTC #6 lore raw

Quoted 2 lines · Felix Fietkau

There are only two parts that need this. The first one is the ath9k virtual wiphy type, no idea when that will change.

I think we're kinda planning to make mac80211 multi-channel aware, at which point it's probably going away. And this could probably be fixed differently too since the nullfunc frames are created internally so don't have _any_ information. Could even use skb->pkt_type I guess.

Quoted 3 lines

The second one is for passing stuff to rate control. That one will go away once we replace ath9k's rc.c ;)
It might just be temporary...

johannes