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
di
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 priority, maybe never
happeni
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 (ips
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
>> > asynchronous crypto via DMA capa
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 plac
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 wrote:
The CCM code goes out of its way to perform the CTR encryption of
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
>>> MAC using the subordinate CTR driver. To this end,
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 from Herbert :)
>
>> If not,
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 r
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 scatterlists so the aead_req
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 t
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
calling
13 matches
Mail list logo