On 26 January 2016 at 13:04, Felix Fietkau <[email protected]> wrote: > On 2016-01-26 12:56, Michal Kazior wrote: >> On 26 January 2016 at 11:45, Felix Fietkau <[email protected]> wrote: >>> On 2016-01-21 14:23, Michal Kazior wrote: >>>> This will allow drivers to make more educated >>>> decisions whether to defer transmission or not. >>>> >>>> Relying on wake_tx_queue() call count implicitly >>>> was not possible because it could be called >>>> without queued frame count actually changing on >>>> software tx aggregation start/stop code paths. >>>> >>>> It was also not possible to know how long >>>> byte-wise queue was without dequeueing. >>>> >>>> Signed-off-by: Michal Kazior <[email protected]> >>> Instead of exposing these in the struct to the driver directly, please >>> make a function to get them. Since the number of frames is already >>> tracked in txqi->queue, you can avoid counter duplication that way. >> >> Hmm, so you suggest to have something like: [...] >>> Also, that way you can fix a race condition between accessing the number >>> of frames counter and the bytes counter. >> >> I don't see a point in maintaining coherency between the two counters >> with regard to each other alone. Do you have a use-case that would >> actually make use of that property? >> >> I'd like to avoid any unnecessary spinlocks. > OK. I guess we can leave them out for now. How frequently are you going > to call this function?
Depends, but with new data path in ath10k[1][2] it'll be at least once for each wake_tx_queue() + once for each txq in each fetch-ind event. Michał [1]: https://patchwork.kernel.org/patch/8081301/ [2]: https://patchwork.kernel.org/patch/8081331/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
