Re: [RFC PATCH 0/5] IPsec parallelization

[Steffen Klassert <steffen.klassert@secunet.com>]

On Tue, Dec 02, 2008 at 04:19:48PM +0800, Herbert Xu wrote:
> On Tue, Dec 02, 2008 at 08:58:04AM +0100, Steffen Klassert wrote:
> > 
> > The parallelization/serialization interface is generic, so the crypto
> > layer can use it in the same way as xfrm.
> 
> I don't really have an opinion on the padata stuff.  What I'm
> objecting to is the way you're putting the parallelism into
> xfrm.
> 
> > The only network specific information that is used is the knowledge
> > of the xfrm_state that a packet uses. On serialization, this helps
> > to stay as parallel as possible. Packets that uses the same state must
> > go to the same cpu (because of the replay window) packets that use
> > different states can go to different cpus.
> 
> Maybe I'm missing somthing, but all you're doing is paralleising
> based on xfrm_state objects.  You can already do that trivially
> in the crypto layer with no network-specific knowledge at all
> because each xfrm_state allocates its own tfm objects.

No, it's not just parallelizing based on xfrm_states. We are running
in parallel even within the same state. That's why I'm getting a 
bandwith up to 900Mbit/s when sending one tcp stream. Parallelizing
based on state would not help that much if you are sending just one
stream.

What happens is that we are sending the packets round robin to
the different cpus on parallelization. On serialization, the
packets will be brought back to the order as they were before the 
parallelization. And to not just send all the packets back to one cpu,
I'm doing parallelization based on xfrm_state after that.

> 
> What I'm proposing is that you create a single parallel crypto
> algorithm template similar to cryptd (FWIW you could even just
> extend cryptd to do this) that does the parallel processing
> based on tfms.
> 
> This achieves exactly the same thing as your current patch-set
> plus:
> 
> 1) The uesr no longer has to make a system-wide choice of whether
> to enable this, instead the control is per-SA through the usual
> algorithm selection mechanism which means that this no longer
> conflicts with async crypto;
> 
> 2) There is no change to the xfrm code;
> 
> 3) The same mechanism can benefit other crypto users such as
> disk encryption.

The padata stuff is generic, so it can be used even for disk
encryption or for anything else that should run in parallel but
needs a certain order at a given point.