On 26 January 2016 at 11:45, Felix Fietkau <nbd@xxxxxxxxxxx> 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 <michal.kazior@xxxxxxxxx>
> 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:
void
ieee80211_get_txq_depth(struct ieee80211_txq *txq,
unsigned int *frame_cnt,
unsigned int *byte_count) {
struct txq_info *txqi = txq_to_info(txq);
if (frame_cnt)
*frame_cnt = txqi->queue.qlen;
if (byte_count)
*byte_cnt = txqi->byte_cnt;
}
Correct?
Sounds reasonable.
> 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.
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
