On 2019-08-15 12:09, Stanislaw Gruszka wrote:
>> Hi Stanislaw,
>>
>> Can you please try if disabling/enabling the tx tasklet during hw key
>> configuration fixes the issue?
>> Doing something like:
>>
>> tasklet_disable(tx_tasklet)
>> mt76x02_set_key()
>> tasklet_enable(tx_tasklet)
>
> It does not help with the problem.
>
>> Moreover, have you double checked if there is any performance impact
>> of not using hw encryption?
>
> I didn't observe any, but realized on this machine I have
> aesni_intel encryption accelerator. After rebuild kernel without
> CONFIG_CRYPTO_AES_NI_INTEL, 'perf top' showed extra 20% of cpu usage
> in aes_encrypt() when sending data with HW encryption disabled.
>
>> If so, I guess it is better to just redefine mt76_wake_tx_queue for
>> mt76x0e and run mt76_txq_schedule for 7630e:
>>
>> void mt76x0e_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
>> {
>> if (is_mt7630(dev)) {
>> mt76_txq_schedule(dev, txq->ac);
>> } else {
>> tasklet_schedule(&dev->tx_tasklet);
>> }
>> }
>
> Not sure about reduction of lock contention for which the tx_tasklet
> was introduced here, but looks ok for me as fix.
I think if we work around the bug like this, it can easily come back to
bite us again later. I don't see any logical explanation as to how this
makes a difference with hardware encryption.
Also, I think it would be helpful to figure out what key operation (if
any) triggers this, adding or removing keys.
Maybe it could also help if we change the order in which the WCID table
entries are updated, i.e. changing MT_WCID_ATTR first when removing keys.
Maybe temporarily clearing MT_MAC_SYS_CTRL_ENABLE_TX before the key
update and setting it again afterwards could also help.
- Felix
