| To: | Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [RFC] Replace scatterlist with crypto_frag |
| From: | Jeff Garzik <jgarzik@xxxxxxxxx> |
| Date: | Fri, 03 Jun 2005 20:02:52 -0400 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxxxxx>, James Morris <jmorris@xxxxxxxxxx>, Linux Crypto Mailing List <linux-crypto@xxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx |
| In-reply-to: | <20050603234623.GA20088@gondor.apana.org.au> |
| References: | <20050603234623.GA20088@gondor.apana.org.au> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 |
Herbert Xu wrote:
The Crypto API doesn't need all the data contained in a scatterlist structure. For instance, it has no need for anything to do with DMA. When we implement hardware crypto (which might do DMA), they're going to have their own lists of descriptors so they can't use the scatterlist as is anyway. I'm not sure I agree with this. A standard feature of struct scatterlist is having the DMA mappings right next to the kernel virtual address/length info. Drivers use the arch-specific DMA-mapped part of struct scatterlist to fill the hardware-specific descriptions with addresses and other info. Since you -will- have to DMA map buffers before passing them to hardware, it seems like struct scatterlist is much more appropriate than crypto_frag when dealing with hardware. For pure software implementations, I don't see why you can't just ignore the extra fields that each arch puts into struct scatterlist. Jeff |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Unitialized queue_lock oops?, Phil Oester |
|---|---|
| Next by Date: | Automated linux kernel testing results, Nivedita Singhvi |
| Previous by Thread: | [RFC] Replace scatterlist with crypto_frag, Herbert Xu |
| Next by Thread: | Re: [RFC] Replace scatterlist with crypto_frag, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |