Re: Help getting aesni crypto patch upstream

[Ben Greear <greearb@candelatech.com>]

On 7/31/20 3:00 AM, Ard Biesheuvel wrote:
> On Fri, 31 Jul 2020 at 01:57, Ben Greear <greearb@candelatech.com> wrote:
>>
>> On 7/29/20 1:06 PM, Ard Biesheuvel wrote:
>>> On Wed, 29 Jul 2020 at 22:29, Ben Greear <greearb@candelatech.com> wrote:
>>>>
>>>> On 7/29/20 12:09 PM, Ard Biesheuvel wrote:
>>>>> On Wed, 29 Jul 2020 at 15:27, Ben Greear <greearb@candelatech.com> wrote:
>>>>>>
>>>>>> On 7/28/20 11:06 PM, Ard Biesheuvel wrote:
>>>>>>> On Wed, 29 Jul 2020 at 01:03, Ben Greear <greearb@candelatech.com> wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> As part of my wifi test tool, I need to do decrypt AES on the CPU, and the only way this
>>>>>>>> performs well is to use aesni.  I've been using a patch for years that does this, but
>>>>>>>> recently somewhere between 5.4 and 5.7, the API I've been using has been removed.
>>>>>>>>
>>>>>>>> Would anyone be interested in getting this support upstream?  I'd be happy to pay for
>>>>>>>> the effort.
>>>>>>>>
>>>>>>>> Here is the patch in question:
>>>>>>>>
>>>>>>>> https://github.com/greearb/linux-ct-5.7/blob/master/wip/0001-crypto-aesni-add-ccm-aes-algorithm-implementation.patch
>>>>>>>>
>>>>>>>> Please keep me in CC, I'm not subscribed to this list.
>>>>>>>>
>>>>>>>
>>>>>>> Hi Ben,
>>>>>>>
>>>>>>> Recently, the x86 FPU handling was improved to remove the overhead of
>>>>>>> preserving/restoring of the register state, so the issue that this
>>>>>>> patch fixes may no longer exist. Did you try?
>>>>>>>
>>>>>>> In any case, according to the commit log on that patch, the problem is
>>>>>>> in the MAC generation, so it might be better to add a cbcmac(aes)
>>>>>>> implementation only, and not duplicate all the CCM boilerplate.
>>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I don't know all of the details, and do not understand the crypto subsystem,
>>>>>> but I am pretty sure that I need at least some of this patch.
>>>>>>
>>>>>
>>>>> Whether this is true is what I am trying to get clarified.
>>>>>
>>>>> Your patch works around a performance bottleneck related to the use of
>>>>> AES-NI instructions in the kernel, which has been addressed recently.
>>>>> If the issue still exists, we can attempt to devise a fix for it,
>>>>> which may or may not be based on this patch.
>>>>
>>>> Ok, I can do the testing.  Do you expect 5.7-stable has all the needed
>>>> performance improvements?
>>>>
>>>
>>> Yes.
>>
>> It does not, as far as we can tell.
>>
>> We did a download test on an apu2 (small embedded AMD CPU, but with
>> aesni support).  A WiFi station is in software-decrypt mode (ath10k-ct driver/firmware,
>> but ath9k would be valid to reproduce the issue as well.)
>>
>> On our 5.4 kernel with the aesni patch applied, we get
>> about 220Mbps wpa2 download throughput.  With open, we get about 260Mbps
>> download throughput.
>>
>> On 5.7, without any aesni patch, we see about 116Mbps download wpa2 throughput,
>> and about 265Mbps open download throughput.
>>
> 
> Thanks for the excellent data. Apparently, FPU preserve/restore is
> still prohibitively expensive on these cores.
> 
> I'll have a stab at implementing cbcmac(aesni) early next week: as i
> pointed out before, we don't need all the ccm boilerplate if the ctr
> and mac processing are still done in separate passes anyway.

That will be very welcome.  We'll be happy to test.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com