Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
To:     Herbert Xu <herbert@gondor.apana.org.au>,
        Ard Biesheuvel <ardb@kernel.org>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Steve deRosier <derosier@cal-sierra.com>
References: <20201201194556.5220-1-ardb@kernel.org>
 <20201201215722.GA31941@gondor.apana.org.au>
 <CAMj1kXHb27ugTWuQZhPD0DvjtgYC8t_pj+igqK7dNfh+WsUS4w@mail.gmail.com>
 <20201201220431.GA32072@gondor.apana.org.au>
 <CAMj1kXGO+kbZ+2VmUQKxLYos2nR5vqZKjengxPxPjSXudG-zLw@mail.gmail.com>
 <20201201221628.GA32130@gondor.apana.org.au>
 <CAMj1kXFrLiHfv1S1AM=5pc1J9gWwZVuoGvmFoTT0-+oREoojTA@mail.gmail.com>
 <20201201231158.GA32274@gondor.apana.org.au>
 <CAMj1kXHwD5ktJTUrh8sndMY7P0kSFhgkGT66YJN1-ONUaU05-g@mail.gmail.com>
 <20201210024342.GA26428@gondor.apana.org.au>
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
Message-ID: <e02fe07e-8cb6-f889-3228-60e4fabf4e40@candelatech.com>
Date:   Wed, 9 Dec 2020 19:01:12 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <20201210024342.GA26428@gondor.apana.org.au>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-MW
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 12/9/20 6:43 PM, Herbert Xu wrote:
> On Thu, Dec 10, 2020 at 01:18:12AM +0100, Ard Biesheuvel wrote:
>>
>> One thing I realized just now is that in the current situation, all
>> the synchronous skciphers already degrade like this.
>>
>> I.e., in Ben's case, without the special ccm implementation, ccm(aes)
>> will resolve to ccm(ctr(aesni),cbcmac(aesni)), which is instantiated
>> as a sync skcipher using the ctr and ccm/cbcmac templates built on top
>> of the AES-NI cipher (not skcipher).  This cipher will also fall back
>> to suboptimal scalar code if the SIMD is in use in process context.
> 
> Sure, your patch is not making it any worse.  But I don't think
> the extra code is worth it considering that you're still going to
> be running into that slow fallback path all the time.

How can we test this assumption?  I see 3x performance gain, so it is not hitting
the fallback path much in my case.  What traffic pattern and protocol do you think
will cause the slow fallback path to happen often enough to make this patch not
helpful?

> Much better to fix the wireless code to actually go async.

This will not happen any time soon, so better to make incremental
improvement in the crypt code.

Thanks,
Ben

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