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]

Message-ID: <20081201111501.GA20650@gondor.apana.org.au>
Date:	Mon, 1 Dec 2008 19:15:01 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	David Miller <davem@...emloft.net>
Cc:	steffen.klassert@...unet.com, netdev@...r.kernel.org,
	klassert@...hematik.tu-chemnitz.de
Subject: Re: [RFC PATCH 0/5] IPsec parallelization

On Mon, Dec 01, 2008 at 02:29:29AM -0800, David Miller wrote:
>
> Herbert, I'm not completely convinced of this line of thinking :-)

Well you've put some doubts into mind for a second there, but
after thinking some more I'm sticking to my position :)

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

No to the first part, but that's not the point.  I'm saying that
you can do flow separation within the crypto layer, well, for
output anyway.  All you need to do is to provide some key to
the crypto layer that tells it that ordering is only required
within that key.  Alternatively, just allocate plenty of crypto
tfms as these patches do, and feed the flows down to different
tfms.

For input there's nothing we can do apart from processing completed
requests in sequence so no flow information is going to help (and
in fact if it did one could argue that the purpose of IPsec has been
defeated :)

> 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.

Well once I've finished the GRO stuff I can give this a go.  But
I'm pretty sure we can achieve exactly the same thing with only
minimal changes to xfrm.  Really all it needs to do is allocate
more tfm objects for the output path.

All the serialisation logic can stay in the crypto layer because
AFAICS no network-specific knowledge is being used in this patch
set.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html