netdev - Re: [RFC PATCH 0/5] IPsec parallelization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 01 Dec 2008 02:29:29 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.apana.org.au
Cc:	steffen.klassert@...unet.com, netdev@...r.kernel.org,
	klassert@...hematik.tu-chemnitz.de
Subject: Re: [RFC PATCH 0/5] IPsec parallelization

From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Mon, 1 Dec 2008 16:49:02 +0800

> On Mon, Dec 01, 2008 at 08:16:14AM +0100, Steffen Klassert wrote:
> > This is a first throw to try to parallelize the expensive part of xfrm by
> > using a generic parallelization/serialization method. This method uses the
> > remote softirq invocation infrastructure for parallelization and serialization.
> > With this method data objects can be processed in parallel, starting 
> > at some given point. After doing some expensive operations in parallel, 
> > it is possible to serialize again. The parallelized data objects return after
> > serialization in the order as they were before the parallelization. 
> > In the case of xfrm, this makes it possible to run the expensive part in
> > parallel without getting packet reordering.
> 
> I still think that you're much better off doing this in the
> crypto layer.  As it stands the only reason why this is attractive
> is because crypto is slow.
> 
> Pretty soon processors will start providing crypto support natively
> so this will no longer be the case.  I'd rather see this stuff
> contained in a small area instead of having it spread all over the
> place as this may become obsolete any day now.

Herbert, I'm not completely convinced of this line of thinking :-)

Will crypto be faster than a routing cache lookup?  Because flow
seperation helps routing performance, significantly.

The problem is that we can't seperate within a flow, that's why we
need something like Steffen's work.

And the reconstitution of the seperated crypto operations into the
original properly ordered flow can be done most cleanly (IMHO) in the
networking layer as far as I have seen so far.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html