On Fri, Apr 16, 2010 at 10:44:37AM +0300, Dmitry Kasatkin wrote:
> Hi,
>
> crypto_ahash_update()
> crypto_ahash_dinup()
> crypto_ahash_final()
>
> obviously might need to return -EINPROGRESS
>
> but can
> crypto_ahash_init(req)
>
> be synchronous?
>
> Or it could also return EINPROGRESS, though not
Hi,
crypto_ahash_update()
crypto_ahash_dinup()
crypto_ahash_final()
obviously might need to return -EINPROGRESS
but can
crypto_ahash_init(req)
be synchronous?
Or it could also return EINPROGRESS, though not sense.
- Dmitry
On 14/04/10 09:55, ext Herbert Xu wrote:
On Wed, Apr 14, 2010 at 0
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: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 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
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
- Original message -
> Hi:
>
> OK so you did answer my question :)
>
> Dmitry Kasatkin wrote:
> >
> > Interesting case with hmac.
> >
> > return crypto_shash_init(&desc.shash) ?:
> > crypto_shash_update(&desc.shash, ipad, bs) ?:
> > crypto_shash_export(&desc.shash, ipad) ?:
> > crypto_
Hi:
OK so you did answer my question :)
Dmitry Kasatkin wrote:
>
> Interesting case with hmac.
>
> return crypto_shash_init(&desc.shash) ?:
>crypto_shash_update(&desc.shash, ipad, bs) ?:
>crypto_shash_export(&desc.shash, ipad) ?:
>crypto_shash_init(&desc.
On Tue, Mar 23, 2010 at 07:32:39PM +0800, Herbert Xu wrote:
>
> My only question is what's your plan with respect to HMAC? If
> you're going to do it in hardware then it's fine as it is.
>
> Otherwise you need to implement export/import and we also need
> to add ahash support to hmac.c.
Dmitry, d
On 23/03/10 13:32, ext Herbert Xu wrote:
On Wed, Mar 17, 2010 at 03:12:49PM +0200, 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.
This driver implements async and sync c
On 23/03/10 13:32, ext Herbert Xu wrote:
On Wed, Mar 17, 2010 at 03:12:49PM +0200, 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.
This driver implements async and sync
On Wed, Mar 17, 2010 at 03:12:49PM +0200, 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.
>
> This driver implements async and sync crypto API.
>
> It still contains pr_debu
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.
This driver implements async and sync crypto API.
It still contains pr_debug() for debugging purpose.
Will be remove for integration.
Dmitry Kasatkin (
34 matches
Mail list logo
