On 10 June 2016 at 11:08, Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: > Michal Kazior <michal.kazior@xxxxxxxxx> writes: > >> For A-MPDU all MPDU rx status (except last one) should share the same >> timestamp. Last one has a different one so all you need is to >> distinguish first and last MPDU. Non A-MPDU obviously are special case >> (status bits are pricky). > > Right. So comparing the rs_stamp between first and last MPDU should give > the duration of the entire thing? Depends on how you define your "thing" :) I no, I don't know what you'll actually measure. It should be reasonable either way. > This would require keeping state > between subsequent calls to the RX handler. Also, what happens if the > last MPDU is lost? No idea. If that's possible, then track last MPDU within PPDU, so you can at least fallback to _something_ when you detect a new first (A-)MPDU? Or maybe it's impossible (i.e. not worth worrying) and HW always reports last MPDU as far as status bits are concerned (regardless of it being _actual_ last MPDU, i.e. it just says "ok, I'm done with this PPDU"). >>> Is the entire A-MPDU received before the RX handler is called for the >>> first frame? >> >> No idea. Maybe it is as there's distinction between "more" and >> "moreaggr". > > Hmm. If it is, comparing the stamp of the first MPDU to the current time > (when handling it) should give the needed duration? Will try doing that > and see what the result is. I'd say it's a little racy/inaccurate (and perhaps unreliable) to compare any kind of global timer and compare it against your rx-status descriptors. Michał -- 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
