Re: [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E

[Felix Fietkau <nbd@nbd.name>]

On 2019-08-19 13:06, Stanislaw Gruszka wrote:
> On Thu, Aug 15, 2019 at 12:20:54PM +0200, Felix Fietkau wrote:
>> 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'm not into workarounds any kind, but this is really strange issue,
> maybe FW bug that triggers just by slightly different driver behaviour.
> 
>> 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.
> 
> Seems not to be related with set_key operation at all. We set 2 HW
> keys at the beginning and hang happen after some tx/rx traffic
> without any re-keyring.
> 
> I'm not sure why disabling HW encryption helps. Maybe it is due to
> ordering or timing. With SW encryption we spend more time in mac80211
> before pass skb's to the driver. Or maybe we just mix some HW keys 
> and SW (group) keys in way that FW does not like.
> 
>> 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.
> 
> I tested below patch and it did not help.
Can you test if disabling hw encryption only for shared or only for
pairwise keys makes any difference?

- Felix