From: Steffen Klassert <steffen.klassert@secunet.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
klassert@mathematik.tu-chemnitz.de
Subject: Re: [RFC PATCH 0/5] IPsec parallelization
Date: Tue, 2 Dec 2008 09:00:31 +0100 [thread overview]
Message-ID: <20081202080031.GE13998@secunet.com> (raw)
In-Reply-To: <20081201084902.GA19904@gondor.apana.org.au>
On Mon, Dec 01, 2008 at 04:49:02PM +0800, Herbert Xu wrote:
> 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.
>
Now, that most of the crypto changes of this patchset are obsolete by
shash, 'spreading all over the place' is probaply not a reason any more
not to keep it in the network layer.
prev parent reply other threads:[~2008-12-02 7:59 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-01 7:16 [RFC PATCH 0/5] IPsec parallelization Steffen Klassert
2008-12-01 7:17 ` [RFC PATCH 1/5] padata: generic interface for parallel processing Steffen Klassert
2008-12-01 7:17 ` [RFC PATCH 2/5] xfrm: add possibility " Steffen Klassert
2008-12-01 7:19 ` [RFC PATCH 3/5] crypto: add possibility to force sync transform Steffen Klassert
2008-12-01 11:22 ` Herbert Xu
2008-12-01 13:19 ` Steffen Klassert
2008-12-01 7:19 ` [RFC PATCH 4/5] crypto: allow allocation of percpu crypto transforms Steffen Klassert
2008-12-01 11:38 ` Herbert Xu
2008-12-01 12:25 ` David Miller
2008-12-01 12:38 ` Herbert Xu
2008-12-01 13:21 ` Steffen Klassert
2008-12-01 7:20 ` [RFC PATCH 5/5] crypto: make struct aead percpu data Steffen Klassert
2008-12-01 11:40 ` Herbert Xu
2008-12-01 13:36 ` Steffen Klassert
2008-12-01 13:44 ` Herbert Xu
2008-12-01 13:47 ` [PATCH 1/6] crypto: hash - Make setkey optional Herbert Xu
2008-12-01 13:47 ` [PATCH 2/6] crypto: null - Switch to shash Herbert Xu
2008-12-01 13:47 ` [PATCH 3/6] crypto: rmd128 " Herbert Xu
2008-12-01 13:47 ` [PATCH 4/6] crypto: rmd160 " Herbert Xu
2008-12-01 13:47 ` [PATCH 5/6] crypto: rmd256 " Herbert Xu
2008-12-01 13:47 ` [PATCH 6/6] crypto: rmd320 " Herbert Xu
2008-12-01 13:51 ` [RFC PATCH 5/5] crypto: make struct aead percpu data Herbert Xu
2008-12-01 13:55 ` Steffen Klassert
2008-12-01 8:49 ` [RFC PATCH 0/5] IPsec parallelization Herbert Xu
2008-12-01 10:29 ` David Miller
2008-12-01 11:15 ` Herbert Xu
2008-12-02 7:58 ` Steffen Klassert
2008-12-02 8:19 ` Herbert Xu
2008-12-02 8:44 ` Steffen Klassert
2008-12-02 8:50 ` Herbert Xu
2008-12-02 9:21 ` Steffen Klassert
2008-12-02 8:53 ` Herbert Xu
2008-12-02 9:39 ` Steffen Klassert
2008-12-02 10:37 ` Herbert Xu
2008-12-01 11:20 ` Andi Kleen
2008-12-01 13:39 ` Herbert Xu
2008-12-02 8:00 ` Steffen Klassert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081202080031.GE13998@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=klassert@mathematik.tu-chemnitz.de \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.