On 6 March 2017 at 20:08, Gilad Ben-Yossef wrote:
>
> I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and
> on Arm using CryptoCell hardware accelerator.
>
> There was no difference in performance between 512 and 4096 bytes
> cluster size on the x86_64 (800 MB loop file system)
On Wed, Mar 1, 2017 at 5:38 PM, Milan Broz wrote:
>
> On 03/01/2017 02:04 PM, Milan Broz wrote:
>> On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
>> ...
>>
>>> I can certainly understand if you don't wont to take the patch until
>>> we have results with
>>> dm-crypt itself but the difference betw
On Wed, Mar 1, 2017 at 3:21 PM, Ondrej Mosnacek wrote:
> 2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef :
>
> Wouldn't adopting a bulk request API (something like what I tried to
> do here [1]) that allows users to supply multiple messages, each with
> their own IV, fulfill this purpose? That way, we
On 03/01/2017 02:04 PM, Milan Broz wrote:
> On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
> ...
>
>> I can certainly understand if you don't wont to take the patch until
>> we have results with
>> dm-crypt itself but the difference between 8 separate invocation of
>> the engine for 512
>> bytes
2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef :
> It really is an observation about overhead of context switches between
> dm-crypt and
> whatever/wherever you handle crypto - be it an off CPU hardware engine
> or a bunch
> of parallel kernel threads running on other cores. You really want to
> burst
On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
...
> I can certainly understand if you don't wont to take the patch until
> we have results with
> dm-crypt itself but the difference between 8 separate invocation of
> the engine for 512
> bytes of XTS and a single invocation for 4KB are pretty big
On Wed, Mar 1, 2017 at 11:29 AM, Milan Broz wrote:
>
> On 03/01/2017 09:30 AM, Gilad Ben-Yossef wrote:
> > On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz wrote:
> >>
> >> On 02/22/2017 07:12 AM, Binoy Jayan wrote:
> >>>
> >>> I was wondering if this is near to be ready for submission (apart from
>
On 03/01/2017 09:30 AM, Gilad Ben-Yossef wrote:
> On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz wrote:
>>
>> On 02/22/2017 07:12 AM, Binoy Jayan wrote:
>>>
>>> I was wondering if this is near to be ready for submission (apart from
>>> the testmgr.c
>>> changes) or I need to make some changes to mak
On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz wrote:
>
> On 02/22/2017 07:12 AM, Binoy Jayan wrote:
> >
> > I was wondering if this is near to be ready for submission (apart from
> > the testmgr.c
> > changes) or I need to make some changes to make it similar to the IPSec
> > offload?
>
> I just t
On 02/22/2017 07:12 AM, Binoy Jayan wrote:
>
> I was wondering if this is near to be ready for submission (apart from
> the testmgr.c
> changes) or I need to make some changes to make it similar to the IPSec
> offload?
I just tried this and except it registers the IV for every new device again,
Hi Herbert,
On 8 February 2017 at 13:02, Gilad Ben-Yossef wrote:
> On Tue, Feb 7, 2017 at 12:35 PM, Binoy Jayan wrote:
>> ===
>> dm-crypt optimization for larger block sizes
>> ===
On 8 February 2017 at 13:02, Gilad Ben-Yossef wrote:
>
> Ran Bonnie++ on it last night (Luks mode, plain64, Qemu Virt platform
> Arm64) and it works just fine.
>
> Tested-by: Gilad Ben-Yossef
>
Hi Gilad,
Thank you for testing it. Do you have access to a device having crypto
hardware with IV ge
On Tue, Feb 7, 2017 at 12:35 PM, Binoy Jayan wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
>
> Currently, the iv generation al
===
dm-crypt optimization for larger block sizes
===
Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move th
14 matches
Mail list logo
