On Thu, Jan 6, 2011 at 2:30 PM, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> The main use-case is bulk encryption/hashing in user-space. For
> example, on Sparc Niagara2 you need to use SPU (Stream Processing
> Unit) in order to do crypto at 10Gb/s over the network.
Umm. But doesn't that require that the data then be sent to the network?
Why would a user-space -> crypto engine -> user space -> network chip
thing ever be good enough? Niagara is so slow that the whole bounce
thing will totally negate all the SPU advantages.
Your interface doesn't seem to support the use case that you actually
want, which is to avoid the bouncing back and forth between user space
buffers.
And if you bounce back and forth, I bet you can't get that 10Gb/s anyway.
Can you do the "bypass directly to the TCP stream" with the interface
you added? It isn't at all obvious how it would work.
So let me repeat ONE MORE TIME:
- I understand that your interface can use the hw that exists
- but I still want real-world use cases to show that it actually
works and makes sense in practice.
Don't give me "we could use the SPU" crap. Give me "this program
actually uses the SPU and gets better performance thanks to it, and
here are the numbers".
Linus
--
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
