| To: | Evgeniy Polyakov <johnpol@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: [patch/RFC]: Asynchronous IPsec processing. |
| From: | Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> |
| Date: | Tue, 3 May 2005 20:14:47 +1000 |
| Cc: | netdev@xxxxxxxxxxx, Patrick McHardy <kaber@xxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Jamal Hadi Salim <hadi@xxxxxxxxxx> |
| In-reply-to: | <1115115502.3414.22.camel@uganda> |
| References: | <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.6+20040907i |
On Tue, May 03, 2005 at 02:18:22PM +0400, Evgeniy Polyakov wrote: > > It can be compile option - those people who wants asynchronous crypto > processing and has appropriate hardware will benefit from that even > if theirs general purpose CPU is VIA with PadLock ACE. Well if there were no better options then we'll have to do that. However, I believe that with the right crypto API we should be able to have async crypto support without sacrificing synchronous performance. > It looks like several CPUs can not be used for synchronous crypto > processing in current IPsec implementation. Using asynchronous That's just an implementation quirk. I will be addressing that soon as part of the xfrm locking clean-up. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [patch/RFC]: Asynchronous IPsec processing., Evgeniy Polyakov |
|---|---|
| Next by Date: | Re: [patch/RFC]: Asynchronous IPsec processing., Evgeniy Polyakov |
| Previous by Thread: | Re: [patch/RFC]: Asynchronous IPsec processing., Evgeniy Polyakov |
| Next by Thread: | Re: [patch/RFC]: Asynchronous IPsec processing., Evgeniy Polyakov |
| Indexes: | [Date] [Thread] [Top] [All Lists] |