Michael Büsch <m@xxxxxxx> writes: > On Thu, 21 May 2020 16:47:41 -0500 > Larry Finger <Larry.Finger@xxxxxxxxxxxx> wrote: > >> On 5/21/20 3:23 PM, Rui Salvaterra wrote: >> > On Thu, 21 May 2020 at 20:19, Rui Salvaterra <rsalvaterra@xxxxxxxxx> wrote: >> >> >> >> Sure, I'll give it a spin. I'm now compiling the kernel for the laptop >> >> with the other b43 card (BCM4311). >> > >> > Nope, kmsg is clean. I'm pretty sure the condition is evaluating to >> > false because we do have the firmware, it's just that the crypto >> > engine doesn't support the required algo. >> > Is hardware encryption an all-or-nothing thing in mac80211? Wouldn't >> > it be possible use the hardware as much as possible and fall back to >> > software only for the unsupported features? (I guess the answer is >> > "no, because the firmware gets in the way", but I had to ask.) >> > >> >> My first failure indicates the mac80211 needs to know from the start that >> software encryption is to be used. The only places that the driver makes note of >> the nohwcrypt is in b43_op_set_key() where it returns -ENOSPC, and our new one >> where MFP_CAPABLE is set. Otherwise, the packet flags indicate that encryption >> is not needed. > > > Thank you all very much for benchmarking this. > > As we see, hwcrypto has a major effect on CPU load. > But I'm still in favor of changing the default to nohwcrypt=1. I'm thinking the same. > That would be a trade off between a wifi that does work with "bad" > performance vs. a wifi that does not work at all by default. And did the "bad" performance even have any real visible changes to the user? IMHO this "bad" performance is small price to pay from getting WPA3 supported out-of-box, especially when the data throughput is unaffected. -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
