2010/6/23 Felix Fietkau <nbd@xxxxxxxxxxx>: > On 2010-06-23 8:47 PM, Björn Smedman wrote: [snip] >> But on the other hand doesn't that also mean that MRR rates and counts >> in the tx status will be incorrect? I.e. one set of rates/counts used >> to transmit the aggregate (first subframe) and (possibly) another set >> reported back in tx status (first acked/expired subframe)? > No, MRR info is just fine. The retry stats are reported for the whole > A-MPDU, not for indvididual subframes. It's always present in the last > descriptor of the whole batch. Also, since my code cleanup a while ago, > the converted rx/tx status info is not longer part of the allocated > descriptor space, but instead kept on stack in the function that > processes the tx status. This on stack tx status is then passed to the > rc update function, which sends the data to mac80211 along with the > AMPDU tx status report. That part looks reasonable to me. The part I don't understand is how ath_tx_rc_update() builds the 'status' field of the 'ieee80211_tx_info' struct. The way I read the code we rely on the compiler laying out the 'status' field on top of the 'control' field (both members of an anonymous union) so that rates and counts align. Since the 'control' field was (presumably) used to set up the tx we already have a 'status' field that is almost correct. We only have to remove the retries that where not actually needed from the counts. But the presumption seems incorrect in the aggregation case. We may be adjusting an MRR series that has never been used to control tx, right? > - Felix > /Björn -- 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
