On Wed, 04 May 2005 06:40:14 -0400
jamal <hadi@xxxxxxxxxx> 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.
> 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().
> 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.
> > 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.
Unfortunately I do not have hardware crypto accelerator setup currently
[board freezes before even monitor and keyboard blink with my HIFN card,
it looks like bus arbitrage problem],
so I can not provide real numbers with it, but I will set acrypto with
several software crypto providers with that patch on SMP
[scheiъe, I burned second HT Xeon] (1+1HT) up, and will rerun the test soon.
> cheers,
> jamal
>
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
|