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