On Wed, 2016-10-19 at 08:59 -0700, Ben Greear wrote:
>
> Do you actually expect performance regressions? I'll be complaining
> if so, but will test first :)
I think we can expect this to use a bit more CPU time, but unless
you're very tight on that you probably shouldn't expect any throughput
On 10/19/2016 08:08 AM, Ard Biesheuvel wrote:
On 19 October 2016 at 08:43, Johannes Berg wrote:
On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote:
We could probably make mac80211 do that too, but can we guarantee in-
order processing? Anyway, it's pretty low
On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote:
> On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
> >
> >
> > Annoyingly, all this complication with scatterlists etc is for
> > doing
> > asynchronous crypto via DMA capable crypto accelerators, and the
> > networking code
On 19 October 2016 at 08:43, Johannes Berg wrote:
> On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote:
>> On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
>> >
>> >
>> > Annoyingly, all this complication with scatterlists etc is for
>> > doing
>> >
On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
>
> Annoyingly, all this complication with scatterlists etc is for doing
> asynchronous crypto via DMA capable crypto accelerators, and the
> networking code (ipsec as well as mac80211, afaik) only allow
> synchronous in the first
On 17 October 2016 at 18:08, Andy Lutomirski wrote:
> On Mon, Oct 17, 2016 at 12:37 AM, Ard Biesheuvel
> wrote:
>> On 17 October 2016 at 08:28, Johannes Berg wrote:
>>> On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel
On Mon, Oct 17, 2016 at 12:37 AM, Ard Biesheuvel
wrote:
> On 17 October 2016 at 08:28, Johannes Berg wrote:
>> On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote:
>>> The CCM code goes out of its way to perform the CTR encryption of the
On Mon, 2016-10-17 at 08:50 +0100, Ard Biesheuvel wrote:
> I just realised that patch should probably use
> aead_request_alloc/aead_request_free [and drop the memset]. That also
> fixes the latent bug where the alignment of the req ctx is not take
> into account.
Good point, I'll fix that up.
>
On 17 October 2016 at 08:47, Johannes Berg wrote:
> On Mon, 2016-10-17 at 08:37 +0100, Ard Biesheuvel wrote:
>>
>> Could we get a statement first whether it is supported to allocate
>> aead_req (and other crypto req structures) on the stack?
>
> Well, we haven't heard
On Mon, 2016-10-17 at 08:37 +0100, Ard Biesheuvel wrote:
>
> Could we get a statement first whether it is supported to allocate
> aead_req (and other crypto req structures) on the stack?
Well, we haven't heard from Herbert :)
> If not, then
> we have our work cut out for us. But if it is, I'd
On 17 October 2016 at 08:28, Johannes Berg wrote:
> On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote:
>> The CCM code goes out of its way to perform the CTR encryption of the
>> MAC using the subordinate CTR driver. To this end, it tweaks the
>> input and output
On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote:
> The CCM code goes out of its way to perform the CTR encryption of the
> MAC using the subordinate CTR driver. To this end, it tweaks the
> input and output scatterlists so the aead_req 'odata' and/or
> 'auth_tag' fields [which may live on
The CCM code goes out of its way to perform the CTR encryption of the MAC
using the subordinate CTR driver. To this end, it tweaks the input and
output scatterlists so the aead_req 'odata' and/or 'auth_tag' fields [which
may live on the stack] are prepended to the CTR payload. This involves
13 matches
Mail list logo