netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).