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 <kim.phillips@xxxxxxxxxxxxx>
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 <kim.phillips@xxxxxxxxxxxxx>
Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
-----Original Message-----
From: Kim Phillips [mailto:kim.phillips@xxxxxxxxxxxxx]
Sent: Friday, April 05, 2013 6:33 PM
To: Hsieh, Che-Min
Cc: linux-crypto@xxxxxxxxxxxxxxx
Subject: Re: questions of crypto async api
On Thu, 4 Apr 2013 14:38:41 +0000
"Hsieh, Che-Min" <cheminh@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
