Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt

[Stanislaw Gruszka <sgruszka@redhat.com>]

On Wed, Mar 13, 2019 at 03:41:50PM +0100, Tom Psyborg wrote:
> >> > It's just matter of sending already encrypted frames. All chipsets
> >> > handle that.
> >> >
> >> > Stanislaw
> >> >
> >>
> >> The question is how well all chipsets handle that. I've seen some lags
> >> too with MFP enabled connection. While being about 40-50% lower,
> >> throughput would still occasionally drop to very low values, like
> >> 800Kbps.
> >
> > The only reason I can image that might have impact on throughput
> > in this case is limited CPU power since encryption is done in
> > software. Would be good to compare with PA2 with nohwcrypte, if
> > there are similar lags. However MFP can require more CPU power.
> >
> > Stanislaw
> >
> 
> nohwcrypt=y mfp=require: there was no throughput drop, no lag,
> measured about 80-85Mbps but the connection frozen after a minute or
> two. might be related to rekeying.
>
> CPU power cannot be the problem since I run it on laptop (2x2.20GHz)

It can be CPU power on AP, ath10k and ath9k also use software
encryption for MFP.

> hwcrypt enabled results are low, some lag but connection remained stable:

There should be no difference between enabling MFP with nohwcrypt and
without nohwcrypt, we will just return -EOPNOTSUPP at different point
from rt2x00mac_set_key:

        if (!rt2x00_has_cap_hw_crypto(rt2x00dev))
                return -EOPNOTSUPP;
<snip>

        crypto.bssidx = rt2x00lib_get_bssidx(rt2x00dev, vif);
        crypto.cipher = rt2x00crypto_key_to_cipher(key);
        if (crypto.cipher == CIPHER_NONE)
                return -EOPNOTSUPP;

However there are some few others points in the code where we check
rt2x00_has_cap_hw_crypto() as well, but all should work the same when
we report to mac80211 that the cipher is not supported.

Stanislaw