On Thu, Jul 12, 2007 at 09:18:33AM +0200, Sebastian Siewior wrote: > > If there is a new IV on *every* request and I don't have to write the IV back > than I put it in my request struct next to the source address :). This indeed > solves my problem. What about jumbo frames in IPsec? Do I get 16 contiguous You mean not writing back the final IV is good enough for you? If so we can probably add a request flag for that. > pages (16 * 4KiB for almost 64KiB which may be encrypted) or is this what you > mean with "the IV is going to change for almost every request" ? They won't be contiguous so yes caching would help here. However this case is exceedingly rare in the wild. > Oh Oh. Where do I get random numbers from? When do you expect me to do > this (aftee request received, request completed or in callback) and what > is this useful for (or how random must the number really be)? I could Well I was hoping that you had a built-in RNG or some such :) > The only thing I'm scared is that I can't use the updated IV for > following requests since it is not updated on enqueue time (my > assumption was that I need this for requests like jumbo frames where the > whole 64k frame is spitted into multiple 8k (smaller) requests and the IV from > previous 8k is required for the following 8k). If your hardware can't chain them up for you then yes you'd have to wait for each chunk to finish before processing the next one. But as I said before this isn't that common at all. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - 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
