> > Some people did volunteer about a month ago but I haven't heard from
> > any of them since ... which means my fixes won't make it into any kernel
> > trees any day soon.
> >
>
> OK. Can you share your git tree again? I will try to ping some people.
>
Well, I just got a response, but in case any
> >
> > How relevant is the fact that there may be (other) situations where latency
> > is not relevant for someone being in a situation where it is relevant?
> >
> > I was just talking about that situation where it actually is relevant and
> > therefore you do *not* wish the hardware driver to be
On Mon, 27 May 2019 at 17:56, Pascal Van Leeuwen
wrote:
>
> > > I understand that as well. But that doesn't change the fact that the
> > > application may be waiting for a loong (relatively speaking) time
> > > for it's results. As latency through hardware may be several orders of
> > > a magn
> > I understand that as well. But that doesn't change the fact that the
> > application may be waiting for a loong (relatively speaking) time
> > for it's results. As latency through hardware may be several orders of
> > a magnitude larger than the time it actually takes to *process* the
> > r
On Mon, 27 May 2019 at 17:16, Pascal Van Leeuwen
wrote:
>
> > > One thing I forgot to mention here that should especially interest you:
> > > you add a lot of complexity to the *driver* that needs to verified and
> > > maintained (by the kernel community?!). Some of these workarounds I had to
> >
> > One thing I forgot to mention here that should especially interest you:
> > you add a lot of complexity to the *driver* that needs to verified and
> > maintained (by the kernel community?!). Some of these workarounds I had to
> > implement are really quite a convoluted mess and it's starting to
On Mon, 27 May 2019 at 14:22, Pascal Van Leeuwen
wrote:
>
> >
> > I understand that. But even if the application is synchronous, it does
> > not mean that the whole world stops and nothing is using the
> > accelerator in the mean time.
> >
> I understand that as well. But that doesn't change the f
On Mon, 27 May 2019 at 14:41, Pascal Van Leeuwen
wrote:
>
> > And if you go that naive route, just fix everything in the driver, then
> > you simply end up with something terribly inefficient because all those
> > corner case checks end up in the fast path and eating up code space.
> >
> One thing
> And if you go that naive route, just fix everything in the driver, then
> you simply end up with something terribly inefficient because all those
> corner case checks end up in the fast path and eating up code space.
>
One thing I forgot to mention here that should especially interest you:
you ad
>
> I understand that. But even if the application is synchronous, it does
> not mean that the whole world stops and nothing is using the
> accelerator in the mean time.
>
I understand that as well. But that doesn't change the fact that the
application may be waiting for a loong (relatively spe
On Mon, 27 May 2019 at 12:43, Pascal Van Leeuwen
wrote:
>
> > As I explained before, what appears synchronous to a single userland
> > process may look very differently from the OS and h/w perspective. But
> > of course, I take your point that h/w is not faster than the CPU in
> > the general case
> As I explained before, what appears synchronous to a single userland
> process may look very differently from the OS and h/w perspective. But
> of course, I take your point that h/w is not faster than the CPU in
> the general case, and so care must be taken.
>
"Synchronous" in this context was re
On Mon, 27 May 2019 at 12:04, Pascal Van Leeuwen
wrote:
>
> > > With all due respect, but you are making assumptions as well. You are
> > > making the assumption that reducing CPU load and/or reducing power
> > > consumption is *more* important than absolute application performance or
> > > latenc
> > With all due respect, but you are making assumptions as well. You are
> > making the assumption that reducing CPU load and/or reducing power
> > consumption is *more* important than absolute application performance or
> > latency. Which is certainly not always the case.
> >
>
> I never said pow
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@kernel.org]
> Sent: Saturday, May 25, 2019 3:23 AM
> To: Ard Biesheuvel
> Cc: Pascal Van Leeuwen ; Christophe Leroy
> ; linux-crypto@vger.kernel.org
> Subject: Re: another testmgr question
>
> On Fri,
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, May 24, 2019 1:10 PM
> To: Pascal Van Leeuwen
> Cc: Christophe Leroy ; linux-crypto@vger.kernel.org
> Subject: Re: another testmgr question
>
> On Fri, 24 May 2019 at 1
On Mon, 27 May 2019 at 11:44, Pascal Van Leeuwen
wrote:
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Friday, May 24, 2019 11:45 AM
> > To: Pascal Van Leeuwen
> > Cc: Christophe Leroy ; linux-crypto@vger.ke
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, May 24, 2019 11:45 AM
> To: Pascal Van Leeuwen
> Cc: Christophe Leroy ; linux-crypto@vger.kernel.org
> Subject: Re: another testmgr question
>
> On Fri, 24 May 2019 at 1
On Fri, May 24, 2019 at 11:25:52AM +0200, Ard Biesheuvel wrote:
>
> All userland clients of the in-kernel crypto use it specifically to
> access h/w accelerators, given that software crypto doesn't require
> the higher privilege level (no point in issuing those AES CPU
> instructions from the kern
On Fri, 24 May 2019 at 11:57, Pascal Van Leeuwen
wrote:
>
> > Again, you are making assumptions here that don't always hold. Note that
> > - a frozen process frees up the CPU to do other things while the
> > crypto is in progress;
> > - h/w crypto is typically more power efficient than CPU crypto;
Le 24/05/2019 à 12:43, Kamil Konieczny a écrit :
On 24.05.2019 12:13, Pascal Van Leeuwen wrote:
True. Those are the "other" reasons - besides acceleration - to use hardware
offload which we often use to sell our IP.
But the honest story there is that that only works out for situations
where t
On 24.05.2019 12:13, Pascal Van Leeuwen wrote:
>> True. Those are the "other" reasons - besides acceleration - to use hardware
>> offload which we often use to sell our IP.
>> But the honest story there is that that only works out for situations
>> where there's enough work to do to make the softwa
> True. Those are the "other" reasons - besides acceleration - to use hardware
> offload which we often use to sell our IP.
> But the honest story there is that that only works out for situations
> where there's enough work to do to make the software overhead for actually
> starting and managing th
> Again, you are making assumptions here that don't always hold. Note that
> - a frozen process frees up the CPU to do other things while the
> crypto is in progress;
> - h/w crypto is typically more power efficient than CPU crypto;
>
True. Those are the "other" reasons - besides acceleration - to
On Fri, 24 May 2019 at 11:34, Pascal Van Leeuwen
wrote:
>
> > All userland clients of the in-kernel crypto use it specifically to
> > access h/w accelerators, given that software crypto doesn't require
> > the higher privilege level (no point in issuing those AES CPU
> > instructions from the kern
> On Fri, May 24, 2019 at 4:47 AM Christophe Leroy
> wrote:
> > ...
> > > As I already mentioned in another thread somewhere, this morning in the
> > > shower I realised that this may be useful if you have no expectation of
> > > the length itself. But it's still a pretty specific use case which w
> All userland clients of the in-kernel crypto use it specifically to
> access h/w accelerators, given that software crypto doesn't require
> the higher privilege level (no point in issuing those AES CPU
> instructions from the kernel if you can issue them in your program
> directly)
>
> Basically,
>
> Apologies, I did not mean to imply that you don't understand your own
> hardware.
>
Not needed at all. That's not how I read it and besides that I'm not
easily offended anyway. Conversely, I don't intend to offend others,
I just enjoy heated discussions ;-) Which I don't mind losing at all,
BTW
Am Freitag, 24. Mai 2019, 11:21:30 CEST schrieb Pascal Van Leeuwen:
Hi Pascal,
> I was not aware of that, so thanks for pointing that out.
> Do they use the async calls (_aio) though? Because otherwise they shouldn't
> end up being hardware accelerated anyway ...
Yes, AIO is supported: http://ch
On Fri, 24 May 2019 at 11:21, Pascal Van Leeuwen
wrote:
>
> > > As I already mentioned in another thread somewhere, this morning in the
> > > shower I realised that this may be useful if you have no expectation of
> > > the length itself. But it's still a pretty specific use case which was
> > > n
> > As I already mentioned in another thread somewhere, this morning in the
> > shower I realised that this may be useful if you have no expectation of
> > the length itself. But it's still a pretty specific use case which was
> > never considered for our hardware. And our HW doesn't seem to be alo
On Fri, 24 May 2019 at 09:47, Pascal Van Leeuwen
wrote:
>
> > > Valid? A totally fabricated case, if you ask me. Yes, you could do that,
> > > but is it *useful* at all? Really?
> >
> > Yes, really. The likelihood of a test vector occurring in practice is
> > entirely irrelevant. What matters is t
On Fri, May 24, 2019 at 4:47 AM Christophe Leroy
wrote:
> ...
> > As I already mentioned in another thread somewhere, this morning in the
> > shower I realised that this may be useful if you have no expectation of
> > the length itself. But it's still a pretty specific use case which was
> > never
Le 24/05/2019 à 10:44, Pascal Van Leeuwen a écrit :
Valid? A totally fabricated case, if you ask me. Yes, you could do that,
but is it *useful* at all? Really?
No, it's not because a file of length 0 is a file of length 0, the length
in itself is sufficient guarantee of its contents. The hash
> > Valid? A totally fabricated case, if you ask me. Yes, you could do that,
> > but is it *useful* at all? Really?
> > No, it's not because a file of length 0 is a file of length 0, the length
> > in itself is sufficient guarantee of its contents. The hash does not add
> > *anything* in this case.
>
> I had the same issue when porting the SEC2 Talitos driver to also
> support SEC1. See following commit to see the way it has been fixed:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id
> =2d02905ebd22c0271a25e424ab209c8b7067be67
>
> Christophe
>
Cristophe,
Tha
> > you can simply do this in the driver instead:
> >
> > if (req->cryptlen == 0)
> > return 0;
>
> +1. It seems like a firmware update in the hardware or a software
> update to the driver are the ways to proceed.
>
Hardware typically does not involve firmware for things li
> > Valid? A totally fabricated case, if you ask me. Yes, you could do that,
> > but is it *useful* at all? Really?
>
> Yes, really. The likelihood of a test vector occurring in practice is
> entirely irrelevant. What matters is that the test vectors provide
> known outputs for known inputs, and ma
On 24.05.2019 07:24, Ard Biesheuvel wrote:
> On Thu, 23 May 2019 at 22:44, Pascal Van Leeuwen
> wrote:
>>
> [...]
> In fact, given the above, I am slightly shocked that your hardware
> does not handle empty messages correctly. [...]
Imho hardware handles it in the way it was designed, for Exynos
Hi Pascal,
Le 23/05/2019 à 23:43, Pascal Van Leeuwen a écrit :
-Original Message-
From: Eric Biggers [mailto:ebigg...@kernel.org]
[...]
Note that it's not necessary that your *hardware* supports empty messages,
since you can simply do this in the driver instead:
if (req->cryp
On Thu, May 23, 2019 at 4:06 PM Eric Biggers wrote:
>
> On Thu, May 23, 2019 at 01:07:25PM +, Pascal Van Leeuwen wrote:
> >
> > I'm running into some trouble with some random vectors that do *zero*
> > length operations. Now you can go all formal about how the API does
> > not explictly disall
On Thu, 23 May 2019 at 22:44, Pascal Van Leeuwen
wrote:
>
> > -Original Message-
> > From: Eric Biggers [mailto:ebigg...@kernel.org]
> > Sent: Thursday, May 23, 2019 10:06 PM
> > To: Pascal Van Leeuwen
> > Cc: linux-crypto@vger.kernel.org
> >
On Thu, May 23, 2019 at 09:43:53PM +, Pascal Van Leeuwen wrote:
> > -Original Message-
> > From: Eric Biggers [mailto:ebigg...@kernel.org]
> > Sent: Thursday, May 23, 2019 10:06 PM
> > To: Pascal Van Leeuwen
> > Cc: linux-crypto@vger.kernel.org
&g
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@kernel.org]
> Sent: Thursday, May 23, 2019 10:06 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: another testmgr question
>
> On Thu, May 23, 2019 at 01:07:25PM +,
On Thu, May 23, 2019 at 01:07:25PM +, Pascal Van Leeuwen wrote:
> Eric,
>
> I'm running into some trouble with some random vectors that do *zero*
> length operations. Now you can go all formal about how the API does
> not explictly disallow this, but how much sense does it really make
> to esse
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@google.com]
> Sent: Thursday, May 23, 2019 8:59 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto-ow...@vger.kernel.org
> Subject: Re: another testmgr question
>
> On Thu, May 23, 2019 at 01:07:25PM +,
46 matches
Mail list logo
