> The old code path in ath_tx_start that would queue packets has been > removed completely, It seems to me that this breaks the ath9k driver when non-data packets which mac80211 will not queue on the new intermediate queues, see ieee80211_drv_tx( ) in mac80211/tx.c where it says if (!ieee80211_is_data(hdr->frame_control)) goto tx_normal; This means that non-data packets can come down from mac80211 via ath_tx --> ath_tx_start which might be for a vif that is not on the same channel, and so cannot be sent straight away but must be queued. Maybe this problem should be fixed in mac80211, but as of now this is a problem. It appears to me that your new patch just sends them on the wrong channel. Maybe I'm confused about something, hints appreciated. > as has the qlen limit tunables (since there's no > longer a queue in the driver to limit). > diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h > index 5294595..daf972c 100644 > --- a/drivers/net/wireless/ath/ath9k/ath9k.h > +++ b/drivers/net/wireless/ath/ath9k/ath9k.h > @@ -91,7 +91,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct ath_descdma *dd, > #define ATH_RXBUF 512 > #define ATH_TXBUF 512 > #define ATH_TXBUF_RESERVE 5 > -#define ATH_MAX_QDEPTH (ATH_TXBUF / 4 - ATH_TXBUF_RESERVE) > #define ATH_TXMAXTRY 13 > #define ATH_MAX_SW_RETRIES 30 I thought the purpose of ATH_MAX_QDEPTH was due to a limit on the depth of a hardware FIFO. Not all packets that get handed to the hardware come through a software queue (e.g. those that bypass the intermediate queueing in mac80211 now) and (it seems to me) there needs to be a limit to prevent overflowing a hardware fifo. Yes, normal data packets are (much) further limited as you taught me a few weeks ago, but not all packets are subject to that constraint (as far as I can understand at the moment). I'm not entirely sure of the details, but I think it is the sorts of packets sent directly by hostapd and wpa_supplicant that bypass all the queueing. And maybe those things aren't likely to be sending a burst of hundreds of packets in a very short period of time (where it could overrun the FIFO), but there may be other tools that send raw 802.11 non-data packets which could then overflow the above limit, and it seems you are removing the check. Actually I think my original version of this patch may have had a flaw in that some combination of non-data and data packets could be combined to overflow this limit (since I failed to check overflowing this limit where I pulled from the mac80211 intermediate queue). My hope is that I'm just confused and you all understand what's really going on better than I do and have an explanation why all the above doesn't matter and is handled in some other way. But in case you don't, I don't want these issues to be overlooked. (I'm not testing using vifs on multiple channels. But even if I was, I'm not sure if normal operation of wpa_supplicant or hostapd would be enough to trigger these problems.) -Tim Shepard shep@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
