On Mon, 8 Apr 2013 13:49:58 +0000 "Hsieh, Che-Min" <chem...@qti.qualcomm.com> 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 <kim.phill...@freescale.com> > 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.phill...@freescale.com> > Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au> > > -----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 +0000 > "Hsieh, Che-Min" <chem...@qti.qualcomm.com> 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
