netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jamal <hadi@cyberus.ca>
To: Miika Komu <miika@iki.fi>
Cc: Dave Dillow <dave@thedillows.org>,
	Patrick McHardy <kaber@trash.net>, Netdev <netdev@oss.sgi.com>
Subject: Re: IPsec performance
Date: Wed, 04 May 2005 07:34:37 -0400	[thread overview]
Message-ID: <1115206478.7665.100.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.GSO.4.58.0505030943310.247@kekkonen.cs.hut.fi>

On Tue, 2005-03-05 at 09:44 +0300, Miika Komu wrote:
> On Tue, 3 May 2005, Dave Dillow wrote:
> 
> > On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote:
> > > However, this does explain why I got only 1.9 megabytes/s with 3DES.
> >
> > What was your hardware? Without knowing what you're running on, it's
> > impossible to tell if that is good or bad.
> >
> > Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz.
> > I get ~2.1MB/s on a 550MHz Athlon.
> 
> Intel Pentium III 500 MHz

I tested on 2.4.x based on Davems code backport and contribution from
Herbert > a year ago on a really bad Xeon 2.0Ghz(?), 32 bit bus mboard,
e1000 NIC. I used a 2.4.x kernel because i was trying to compare against
a broadcom SB1250 board which couldnt run 2.6.x - I also had to do a few
tricks to get it to run/compile on MIPS and so may have contributed to
perfomance degradation. 
In any case, the numbers between those two were not very different (even
though the sb1250 was at i think 600Mhz). Unfortunately i lost the
loaner sb1250 shortly after (it was fun to play with). I have my full
results somewhere in another machine which i can lookup, but heres some
summary data i had in my laptop:

used:
A) i) two flows ii) 4 flows iii) 8 flows
all seem to reproduce the same aggregate throughput. 

B) static keying


Tests and results
-----------------

I: Transport mode:

1) Message Authentication: tested with hmac-md5
Should have done sha-1. Next time.

a) 64 byte packets
Input 100Mbps (148.8Kpps) output 112 Kpps

This is about 75% of wire rate (75Mbps).

b) 1400 byte packets
8712 (99% of wire rate) == about 17.4Kpps which is almost
wire rate at 200Mbps at that packet size.
Note we can never get 100% wire rate since the packet header grows
because of the AH insertion.

2) Data encryption mode: 3DES/md5

a) 64 byte packets
Peak achievement:
43Kpps == 30Mbps.

b) 1400 byte packets
Peak achievement:
1.8Kpps == 20Mbps.

Now this result is very interesting. It clearly shows that 3DES
is compute intensive i.e as the packet grows you get slower - quiet
counterintuitive. 
An encryption chip would go along way to help with large packet sizes.
Another observation:
In other words given the synchronous nature of the crypto path, there is
a threshold value where it may be valuable to use a crypto chip.
The effects of this were actually demonstrated by Eugene Surovegin
<ebs@ebshome.net>; long thread of discussion on this on netdev.

We need to find the threshold packet size where encryption starts
overtaking general packet processing i.e where offloading becomes
interesting if we stick with sync scheme.

Another thing for s/ware based crypto is to improve the 3DES
implementation as in assembler coding.

Iam back on/off playing with this, so expect more results Real Soon Now.


cheers,
jamal

  parent reply	other threads:[~2005-05-04 11:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-02 18:39 IPsec performance Miika Komu
2005-05-02 19:09 ` Miika Komu
2005-05-03  0:55   ` Patrick McHardy
2005-05-03  5:25     ` Miika Komu
2005-05-03  5:54       ` Dave Dillow
2005-05-03  6:44         ` Miika Komu
2005-05-03 14:17           ` Dave Dillow
2005-05-03 16:14             ` Miika Komu
2005-05-03 19:27               ` Dave Dillow
2005-05-03 19:27                 ` David S. Miller
2005-05-04 11:34           ` jamal [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-12-29 21:09 ipsec performance Andreas Schuldei
2009-12-29 22:55 ` Abhijit Karmarkar
2009-12-29 23:31   ` Andreas Schuldei

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=1115206478.7665.100.camel@localhost.localdomain \
    --to=hadi@cyberus.ca \
    --cc=dave@thedillows.org \
    --cc=kaber@trash.net \
    --cc=miika@iki.fi \
    --cc=netdev@oss.sgi.com \
    /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).