Hi, See inline... -----Original Message----- From: Herbert Xu [mailto:herbert@xxxxxxxxxxxxxxxxxxx] Sent: Thursday, May 29, 2008 12:02 AM To: Loc Ho Cc: linux-crypto@xxxxxxxxxxxxxxx Subject: Re: IPSec ESP Authenc Offload On Wed, May 28, 2008 at 04:02:11PM -0700, Loc Ho wrote: >> >> It doesn't help if it is generated by software. The driver still needs >> a context SA for each operation. In addition, the driver will have to >> increment seq (or load from request) and load SEQ and IV into each >> context SA. It is much cleaner if our driver knows the whole header >> length. Even if the hardware rewrites the SPI and SEQ again, it is all >> handled by hardware offload and will not be a problem for IPSEC ESP. > >I'm happy to add support for ESP offload. However, I don't think we should add it onto the >AEAD interface. We should instead create an ESP interface that specifically does this. > [Loc Ho] I agree if we are doing complete ESP offload. Right now, we just want to handle 'authenc' offload and not hanving to deal with complete offload. >I still think that you can use the existing interface though and just throw away the ESP >work since that's trivial anyway. Having a context SA is not a problem since each tfm >corresponds to a single SA and you can just store the context in its context area. > [Loc Ho] I would like to use the existent interface and it does work. Except, it will require extra works such as 1) another context SA per an operation (this is in addition to the context SA with the tfm), 2) as there are now multiple context SA's, they need to be in sync, and 3) copy fields from one context SA to another. We can not use the same context SA for per operation for following reasons: 1. For hardware generated IV, we need to store the IV in per context SA per operation so that we can write back into the packet by software. 2. For software generated IV, we need to store the IV in per context SA per operation for the hardware to access for crypto algorithm. Alternative, we can parse the IP header if this information is not available from the request 'struct skcipher_givcrypt_request'. This would avoid per context SA per operation. But this is extra work as it is already available in IPSec ESP. -Loc -- 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
