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

[jamal <hadi@cyberus.ca>]

On Wed, 2005-04-05 at 20:11 +0400, Evgeniy Polyakov wrote:
> On Wed, 04 May 2005 06:40:14 -0400
> jamal <hadi@cyberus.ca> wrote:
> 
> > 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?
> 
> Yes, it is vanilla 2.6.12-rc2 kernel with native IPsec.
> 

Very nice numbers then - considering the async was at least delaying
things by at least a jiffie.


> > 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;
> 
> That could be skb too - since both skb/kmalloc 
> atomic allocations end up in kmem_cache_alloc().

The skb is a little tricky in particular if you allocate in one CPU and 
free on another. If this could happen with the esp_async struct as well
then it is not worth it.

>  
> > BTW, you may need to incr ref counter of x pre-callback and decrement
> > when done in callback.
> 
> It looks like dst entry holding is enough since 
> direct dst->output(), i.e. xfrm_state->output(), 
> call itself is not protected by reference counter,
> but dst entry is being held during that call.
> 

makes sense.

cheers,
jamal