On Wed, Apr 14, 2010 at 09:51:22AM +0300, Dmitry Kasatkin wrote:
>
> What do you mean by "merge operation".
> request merging?
By buffering user data, you're in essence merging requests.
I have no objections to doing that, but let's not do it in every
driver.
Of course, the ultimate solution is
On 14/04/10 09:44, ext Herbert Xu wrote:
On Wed, Apr 14, 2010 at 09:37:47AM +0300, Dmitry Kasatkin wrote:
Like just with import/export.
Problems for hw:
1. To have a good performance with DMA we need to have large buffer.
Not just 64 bytes block. state becomes large
Sure. But
On Wed, Apr 14, 2010 at 09:41:28AM +0300, Dmitry Kasatkin wrote:
>
> what do you mean "exporting shash object"?
>
> Providing shash alg?
>
> I was not sure if it is needed if ahash is available.
>
> Should I remove shash alg at all?
In that case please remove the shash object. ahash by itself
is
On Wed, Apr 14, 2010 at 09:37:47AM +0300, Dmitry Kasatkin wrote:
>
> Like just with import/export.
> Problems for hw:
>
> 1. To have a good performance with DMA we need to have large buffer.
> Not just 64 bytes block. state becomes large
Sure. But it shouldn't be up to the driver to merge ope
On 14/04/10 09:20, ext Herbert Xu wrote:
Dmitry Kasatkin wrote:
Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
was not ported to new crypto APIs and removed from the source tree.
- implements async and sync crypto API using dma and cpu.
- supports multiple s
Hi,
I am thinking to update to have:
- concurrent requests with queue.
- import/export problem
but it takes a time.
- Dmitry
On 14/04/10 09:20, ext Herbert Xu wrote:
Dmitry Kasatkin wrote:
Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
was not ported to ne
On 14/04/10 03:44, ext Herbert Xu wrote:
On Tue, Apr 13, 2010 at 06:21:44PM +0300, Dmitry Kasatkin wrote:
On 13/04/10 18:16, ext Uri Simchoni wrote:
Doing step 3 using sw is probably faster than by hw (because it's short and
avoid all the hw setup), so the suggested approach is pr
Dmitry Kasatkin wrote:
> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
> was not ported to new crypto APIs and removed from the source tree.
>
> - implements async and sync crypto API using dma and cpu.
> - supports multiple sham instances if available
>
> Signed-o
On Tue, Apr 13, 2010 at 06:48:42PM +0300, Dmitry Kasatkin wrote:
>
> About import/export.
>
> The problem with HW is that it always handles 64 byte blocks except last
> one.
> So until finup/final it is not known if it is the last data. So some
> buffer is kept in context.
>
> With DMA it is ve
On Tue, Apr 13, 2010 at 06:33:59PM +0300, Dmitry Kasatkin wrote:
>
> Then state must be kept in req ctx, not tfm ctx.
> Right?
Correct, the same thing applies to both shash and ahash.
> Then when handling different request HW must be re-initialized.
> If handling the same request then no need to
On Tue, Apr 13, 2010 at 06:21:44PM +0300, Dmitry Kasatkin wrote:
>
>
> On 13/04/10 18:16, ext Uri Simchoni wrote:
>> Doing step 3 using sw is probably faster than by hw (because it's short and
>> avoid all the hw setup), so the suggested approach is probably faster than
>> generic async hmac.
>>
About import/export.
The problem with HW is that it always handles 64 byte blocks except last
one.
So until finup/final it is not known if it is the last data. So some
buffer is kept in context.
With DMA it is very inefficient to have small buffer.
I use page 4k for that.
So after a certain
On 13/04/10 17:42, ext Herbert Xu wrote:
On Tue, Apr 13, 2010 at 05:36:40PM +0300, Dmitry Kasatkin wrote:
Also one more question.
can reqa and reqb could come from the same tfm as well?
Yes of course.
Two packets coming from different CPUs going to through the same
IPsec SA for in
On 13/04/10 18:16, ext Uri Simchoni wrote:
Doing step 3 using sw is probably faster than by hw (because it's short and
avoid all the hw setup), so the suggested approach is probably faster than
generic async hmac.
Yes. that is exactly what happens in hw - it is much slower.
And I do not
Doing step 3 using sw is probably faster than by hw (because it's short and
avoid all the hw setup), so the suggested approach is probably faster than
generic async hmac.
On 4/13/2010 5:45 PM, Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 04:00:11PM +0300, Dmitry Kasatkin wrote:
>>
>> I would also
On Tue, Apr 13, 2010 at 04:44:35PM +0300, Dmitry Kasatkin wrote:
>
> Well it can... if reqa occupied hw all other requests will fallback to
> sw sha1.
That is unacceptable. If we had a user-space API that would
mean a single request can tie up the hardware indefinitely.
If your hardware is not
On Tue, Apr 13, 2010 at 04:00:11PM +0300, Dmitry Kasatkin wrote:
>
> I would also:
> 1. calc hash(opad) using sw, export
> 2. hash(ipad ∥ message) using hw
> 3. then import and finup hash from step 1 with results of step 2 (using sw)
Step 3 is the problem. If you perform step 3 in software then
t
On Tue, Apr 13, 2010 at 05:36:40PM +0300, Dmitry Kasatkin wrote:
> Also one more question.
>
> can reqa and reqb could come from the same tfm as well?
Yes of course.
Two packets coming from different CPUs going to through the same
IPsec SA for instance.
Cheers,
--
Visit Openswan at http://www.o
Also one more question.
can reqa and reqb could come from the same tfm as well?
thanks
On 13/04/10 16:44, Kasatkin Dmitry (Nokia-D/Helsinki) wrote:
Please see inline. Nice to clarify it.
On 13/04/10 15:10, ext Herbert Xu wrote:
On Tue, Apr 13, 2010 at 01:15:34PM +0300, Dmitry Kasatkin wr
Please see inline. Nice to clarify it.
On 13/04/10 15:10, ext Herbert Xu wrote:
On Tue, Apr 13, 2010 at 01:15:34PM +0300, Dmitry Kasatkin wrote:
But anyway hmac does not support ahash now. right?
So the only way currently is to add to the driver.
No the only way is to add an ahash ve
On 13/04/10 15:02, ext Herbert Xu wrote:
On Tue, Apr 13, 2010 at 01:13:47PM +0300, Dmitry Kasatkin wrote:
As I can see from the patch initial vectors calculated with SW shash
Rest is done in hw, basically sha1.
Ideally that code shouldn't be duplicated either, but honestly
that doesn'
On Tue, Apr 13, 2010 at 01:15:34PM +0300, Dmitry Kasatkin wrote:
>
> But anyway hmac does not support ahash now. right?
> So the only way currently is to add to the driver.
No the only way is to add an ahash version of hmac.
Anyway, the fact that you can't easily implement import/export
is not ju
On Tue, Apr 13, 2010 at 01:13:47PM +0300, Dmitry Kasatkin wrote:
>
> As I can see from the patch initial vectors calculated with SW shash
> Rest is done in hw, basically sha1.
Ideally that code shouldn't be duplicated either, but honestly
that doesn't matter when it comes to whether the hardware c
The Marvell CESA needs some software assistance in doing HMAC - the inner and
outer blocks need
to be prepared and hashed (partial hash). The hash results are fed into the
hardware and the hardware uses it
as IVs and does the two hash operations. So in effect the HW hmac(sha1) driver
needs softw
Btw.
But anyway hmac does not support ahash now. right?
So the only way currently is to add to the driver.
On 13/04/10 13:03, ext Herbert Xu wrote:
On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
btw. patch to mv_cesa is actually adding hmac to the driver.
How would you c
Hi
On 13/04/10 13:03, ext Herbert Xu wrote:
On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
btw. patch to mv_cesa is actually adding hmac to the driver.
How would you comment that?
AFAICS it's doing HMAC in hardware. Uri, is that not the case?
As I can see fro
On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
>
> btw. patch to mv_cesa is actually adding hmac to the driver.
> How would you comment that?
AFAICS it's doing HMAC in hardware. Uri, is that not the case?
> The same way could be also used here.
If your hardware supports HMAC t
Hi,
btw. patch to mv_cesa is actually adding hmac to the driver.
How would you comment that?
The same way could be also used here.
I could calc final output with sw.
Any comments?
- Dmitry
On 13/04/10 11:59, ext Herbert Xu wrote:
On Thu, Apr 08, 2010 at 06:35:33PM +0200, dmitry.kasat...@no
On Thu, Apr 08, 2010 at 06:35:33PM +0200, dmitry.kasat...@nokia.com wrote:
>
> Sha1 only is also very useful. We calcluate hashes of all binaries for
> integrity verification. We do not need hmac there.
But do we do that in the Linux kernel?
Of course it would be useful if we had a user-space A
On Thu, Apr 08, 2010 at 07:25:15PM +0300, Uri Simchoni wrote:
> This is a resubmission of a patchset I set a while ago, and that was
> corrupted by my email client.
>
> The following patchset adds async hashing (sha1 and hmac-sha1) to the mv_cesa
> crypto driver. This driver utilizes the Marvell
Changes to v2:
- Added multi omap kernel support based on comment
- some redundant vars removed
Dmitry Kasatkin (2):
crypto: updates omap sham device related platform code
crypto: omap-sham - omap sha1 & md5 driver
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/cl
- registration with multi OMAP kernels support
- clocks
Signed-off-by: Dmitry Kasatkin
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/devices.c
Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
was not ported to new crypto APIs and removed from the source tree.
- implements async and sync crypto API using dma and cpu.
- supports multiple sham instances if available
Signed-off-by: Dmitry Kasatkin
---
drivers/c
33 matches
Mail list logo
