On 2019-10-10 04:43, Yibo Zhao wrote:
> Hi Felix,
>
> In ath10k, we might have situations like,
>
> CPU0 CPU1
> ... ieee80211_txq_schedule_start()
> ... while(ieee80211_next_txq()) {
> ... driver dequeue packets from
> txq
> ... ieee80211_return_txq()
> ieee80211_txq_schedule_start() ...
> ieee80211_next_txq() }
> driver dequeue packets from txq ieee80211_txq_schedule_end()
> ieee80211_return_txq()
> ieee80211_txq_schedule_end()
>
> The problem is while CPU1 is looping to dequeue txqs, the schedule_round
> which is used to make sure no infinite loop will be changed in CPU0. So
> a txq has already been scheduled will be scheduled again then the loop
> won't be end at that point as our expected.
Hi,
I think this is something that should be fixed in the driver. The
comment for ieee80211_txq_schedule_start() already states:
"The driver must not call multiple TXQ scheduling rounds concurrently"
The way that I'm dealing with this in mt76 is that I ensure that all txq
scheduling is done from a single tasklet, which is scheduled from the tx
status and the queue wake path.
I think that approach should perform well in ath10k as well, and it will
avoid the cost of waiting for a lock on one CPU while the other is
scheduling tx already.
- Felix
