If a driver supports multiple instances of HW crypto engines, the order of?the request completion from HW can be different from the order of requests submitted?to different HW.? The 2nd request sent out to the 2nd?HW instance may take shorter time to complete than the first request?for different HW instance.? Is the driver responsible for re-ordering the completion callout? Or the agents (such as IP protocol stack) are responsible for reordering? How does pcrypt do it?
?Does it make sense for a transform to send multiple requests outstanding to async crypto api?
?Is scatterwalk_sg_next() preferred method over sg_next()?? Why?
?sg_copy_to_buffer() and sg_copy_from_buffer() -> sg_copy_buffer()->sg_copy_buffer() -> sg_miter_next()-> sg_next()
Sometimes sg_copy_to_buffer() and sg_copy_from_buffer() in our driver do not copy the whole list. We have to rewrite those functions by using scattewalk_sg_next() to walk down the list. Is this the correct behavior?
Thanks.
Chemin
On Thu, 4 Apr 2013 14:38:41 +0000
"Hsieh, Che-Min" <[email protected]> wrote:
> If a driver supports multiple instances of HW crypto engines, the order of?the request completion from HW can be different from the order of requests submitted?to different HW.? The 2nd request sent out to the 2nd?HW instance may take shorter time to complete than the first request?for different HW instance.? Is the driver responsible for re-ordering the completion callout? Or the agents (such as IP protocol stack) are responsible for reordering? How does pcrypt do it?
>
> ?Does it make sense for a transform to send multiple requests outstanding to async crypto api?
see:
http://comments.gmane.org/gmane.linux.kernel.cryptoapi/5350
> ?Is scatterwalk_sg_next() preferred method over sg_next()?? Why?
scatterwalk_* is the crypto subsystem's version of the function, so
yes.
> ?sg_copy_to_buffer() and sg_copy_from_buffer() -> sg_copy_buffer()->sg_copy_buffer() -> sg_miter_next()-> sg_next()
> Sometimes sg_copy_to_buffer() and sg_copy_from_buffer() in our driver do not copy the whole list. We have to rewrite those functions by using scattewalk_sg_next() to walk down the list. Is this the correct behavior?
sounds like you're on the right track, although buffers shouldn't be
being copied that often, if at all.
Kim
Thanks for the answer.
I have further question on the same subject.
With regard to the commit in talitos.c, (attached at end of this mail),
the driver submits requests of same tfm to the same channel to ensure the ordering.
Is it because the tfm context needs to be maintained from one operation to next operation? Eg, aead_givencrypt() generates iv based on previous iv result stored in tfm.
If requests are sent to different channels dynamically. And driver at the completion of a request from HW, reorders the requests completion callback, what would happen?
Thanks in advance.
Chemin
commit 5228f0f79e983c2b39c202c75af901ceb0003fc1
Author: Kim Phillips <[email protected]>
Date: Fri Jul 15 11:21:38 2011 +0800
crypto: talitos - ensure request ordering within a single tfm
Assign single target channel per tfm in talitos_cra_init instead of
performing channel scheduling dynamically during the encryption request.
This changes the talitos_submit interface to accept a new channel
number argument. Without this, rapid bursts of misc. sized requests
could make it possible for IPsec packets to be encrypted out-of-order,
which would result in packet drops due to sequence numbers falling
outside the anti-reply window on a peer gateway.
Signed-off-by: Kim Phillips <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
-----Original Message-----
From: Kim Phillips [mailto:[email protected]]
Sent: Friday, April 05, 2013 6:33 PM
To: Hsieh, Che-Min
Cc: [email protected]
Subject: Re: questions of crypto async api
On Thu, 4 Apr 2013 14:38:41 +0000
"Hsieh, Che-Min" <[email protected]> wrote:
> If a driver supports multiple instances of HW crypto engines, the order of?the request completion from HW can be different from the order of requests submitted?to different HW.? The 2nd request sent out to the 2nd?HW instance may take shorter time to complete than the first request?for different HW instance.? Is the driver responsible for re-ordering the completion callout? Or the agents (such as IP protocol stack) are responsible for reordering? How does pcrypt do it?
>
> ?Does it make sense for a transform to send multiple requests outstanding to async crypto api?
see:
http://comments.gmane.org/gmane.linux.kernel.cryptoapi/5350
> ?Is scatterwalk_sg_next() preferred method over sg_next()?? Why?
scatterwalk_* is the crypto subsystem's version of the function, so yes.
> ?sg_copy_to_buffer() and sg_copy_from_buffer() ->
> sg_copy_buffer()->sg_copy_buffer() -> sg_miter_next()-> sg_next() Sometimes sg_copy_to_buffer() and sg_copy_from_buffer() in our driver do not copy the whole list. We have to rewrite those functions by using scattewalk_sg_next() to walk down the list. Is this the correct behavior?
sounds like you're on the right track, although buffers shouldn't be being copied that often, if at all.
Kim
On Mon, 8 Apr 2013 13:49:58 +0000
"Hsieh, Che-Min" <[email protected]> wrote:
> Thanks for the answer.
>
> I have further question on the same subject.
> With regard to the commit in talitos.c, (attached at end of this mail),
> the driver submits requests of same tfm to the same channel to ensure the ordering.
>
> Is it because the tfm context needs to be maintained from one operation to next operation? Eg, aead_givencrypt() generates iv based on previous iv result stored in tfm.
is that what the commit text says?
> If requests are sent to different channels dynamically. And driver at the completion of a request from HW, reorders the requests completion callback, what would happen?
about the same thing as wrapping the driver with pcrypt? why not
use the h/w to maintain ordering?
Kim
> Thanks in advance.
>
> Chemin
>
>
>
> commit 5228f0f79e983c2b39c202c75af901ceb0003fc1
> Author: Kim Phillips <[email protected]>
> Date: Fri Jul 15 11:21:38 2011 +0800
>
> crypto: talitos - ensure request ordering within a single tfm
>
> Assign single target channel per tfm in talitos_cra_init instead of
> performing channel scheduling dynamically during the encryption request.
> This changes the talitos_submit interface to accept a new channel
> number argument. Without this, rapid bursts of misc. sized requests
> could make it possible for IPsec packets to be encrypted out-of-order,
> which would result in packet drops due to sequence numbers falling
> outside the anti-reply window on a peer gateway.
>
> Signed-off-by: Kim Phillips <[email protected]>
> Signed-off-by: Herbert Xu <[email protected]>
>
> -----Original Message-----
> From: Kim Phillips [mailto:[email protected]]
> Sent: Friday, April 05, 2013 6:33 PM
> To: Hsieh, Che-Min
> Cc: [email protected]
> Subject: Re: questions of crypto async api
>
> On Thu, 4 Apr 2013 14:38:41 +0000
> "Hsieh, Che-Min" <[email protected]> wrote:
>
> > If a driver supports multiple instances of HW crypto engines, the order of?the request completion from HW can be different from the order of requests submitted?to different HW.? The 2nd request sent out to the 2nd?HW instance may take shorter time to complete than the first request?for different HW instance.? Is the driver responsible for re-ordering the completion callout? Or the agents (such as IP protocol stack) are responsible for reordering? How does pcrypt do it?
> >
> > ?Does it make sense for a transform to send multiple requests outstanding to async crypto api?
>
> see:
>
> http://comments.gmane.org/gmane.linux.kernel.cryptoapi/5350
>
> > ?Is scatterwalk_sg_next() preferred method over sg_next()?? Why?
>
> scatterwalk_* is the crypto subsystem's version of the function, so yes.
>
> > ?sg_copy_to_buffer() and sg_copy_from_buffer() ->
> > sg_copy_buffer()->sg_copy_buffer() -> sg_miter_next()-> sg_next() Sometimes sg_copy_to_buffer() and sg_copy_from_buffer() in our driver do not copy the whole list. We have to rewrite those functions by using scattewalk_sg_next() to walk down the list. Is this the correct behavior?
>
> sounds like you're on the right track, although buffers shouldn't be being copied that often, if at all.
>
> Kim
>
>