[Top] [All Lists]

Re: [patch/RFC]: Asynchronous IPsec processing benchmark.

To: johnpol@xxxxxxxxxxx
Subject: Re: [patch/RFC]: Asynchronous IPsec processing benchmark.
From: jamal <hadi@xxxxxxxxxx>
Date: Wed, 04 May 2005 06:40:14 -0400
Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, Patrick McHardy <kaber@xxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>
In-reply-to: <1115127507.3414.58.camel@uganda>
Organization: unknown
References: <20050429144103.A23268@xxxxxxxxxxx> <20050503095312.GA29788@xxxxxxxxxxxxxxxxxxx> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@xxxxxxxxxxxxxxxxxxx> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@xxxxxxxxxxxxxxxxxxx> <1115117728.3414.48.camel@uganda> <1115127507.3414.58.camel@uganda>
Reply-to: hadi@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Tue, 2005-03-05 at 17:38 +0400, Evgeniy Polyakov wrote:
> Here are some numbers:
> ./netperf -l 60 -H gw -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344
> -S 57344
> TCP STREAM TEST to gw : +/-2.5% @ 99% conf.
> async-ipsec, 10^6bits/sec:  35.42
>  sync-ipsec, 10^6bits/sec:  37.11
> So even with existing timer deferring it is not noticebly slower [about
> 4%].

by "sync" i hope you mean the original code without your change?

The one thing i see in your POC code that may affect numbers a bit is
allocation of struct esp_async every time in the path. Perhaps precreate
a pool of those and then just grab/return to/fro pool; 
BTW, you may need to incr ref counter of x pre-callback and decrement
when done in callback.

> And I think that benefits it provides definitely cost that price and 
> compile time option.

I think Herberts concerns about latency should go away if you really
have some proper crypto hardware. 


<Prev in Thread] Current Thread [Next in Thread>