netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Dillow <dave@thedillows.org>
To: netdev@oss.sgi.com
Cc: dave@thedillows.org
Subject: [RFC BK 0/22] xfrm offload v2: Add hardware assist for IPSEC crypto
Date: Mon, 10 Jan 2005 10:36:58 -0500	[thread overview]
Message-ID: <20040110014300.01@ori.thedillows.org> (raw)

The following patch set adds hardware offload of the crypto operations for
IPv4 IPSEC processing. It gives a noticible speedup on my (admittedly older)
hardware, but given the recent numbers posted, can be a speedup even for
more recent hardware.

There are a few known issues with the current patchset, but I think it is
ready for wider review. This version incorporates a few comments from the
mailing lists, and removes GFP_ATOMIC allocations.

* Only the 3Com 3CR990 family of NICs are supported. I don't have hardware
	or documentation for the Intel cards.
* Doesn't do IPv6. Need someone to implement map_direction(), and
	AH/ESP handling, as well as come up with a card that supports it.
* linux/skbuff.h cannot include net/xfrm.h currently, so there are
	redundant defines (requires some header cleanup, which I'm not
	very inclined to tackle at the moment.)
* TCP Segmentation offload seems broken by firmware 03.001.008. It could be
	my changes to support the offload, but that seems unlikely. I will
	have to investigate this.
* Latency suffers somewhat on smaller packets, it may be advisable to have
	a minimum packet size to offload.
* No real feedback on which xfrm_states have been offloaded or not.
* No individual control over which xfrm_states are allowed to be offloaded.

The patch set will be sent as follow-ups to this post, or is available via:

	bk pull http://typhoon.bkbits.net/ipsec-2.6

If you have pulled from there before, you will need to reclone, as the
repository has been recreated.

It will update the following files:

 Documentation/networking/netdevices.txt |   16 
 drivers/net/typhoon.c                   |  720 +++++++++++++++++++++++++++++++-
 drivers/net/typhoon.h                   |   38 +
 include/linux/ethtool.h                 |    8 
 include/linux/netdevice.h               |   10 
 include/linux/skbuff.h                  |   55 ++
 include/net/dst.h                       |    2 
 include/net/xfrm.h                      |  102 ++++
 net/core/ethtool.c                      |   54 ++
 net/core/skbuff.c                       |   31 +
 net/ipv4/ah4.c                          |   99 ++--
 net/ipv4/esp4.c                         |  102 ++--
 net/ipv4/xfrm4_state.c                  |    9 
 net/ipv6/xfrm6_state.c                  |   10 
 net/xfrm/xfrm_export.c                  |    4 
 net/xfrm/xfrm_policy.c                  |   85 +++
 net/xfrm/xfrm_state.c                   |   99 ++++
 17 files changed, 1329 insertions(+), 115 deletions(-)

If you work from the mailed patches, you will want the netdev-2.6 updates
to the typhoon driver, as the 3CR990B series needs the newest firmware to
correctly offload IPSEC processing. That patch is available from

http://www.thedillows.org/typhoon-netdev-2.6.patch.bz2


The following results were generated using a dual processor PIII 1GHz/512MB
with a 3CR990SVR97 (ori) and an Athlon 550 MHz/256MB with a 3CR990B (tank).
Latency testing was performed with lmbench's lat_tcp, and bandwith testing
was performed with Andrew Morton's zcc/zcs/cyclesoak. I ran the tests
multiple times, and picked the median results to report. There was not much
deviation in the results (+/- 1.5 us +/- 50KBytes/s +/- 1.5% CPU usage).


TCP Latency tests (1 byte msg)

Config					Latency
No IPSEC				196 us
AH/SHA1 (sw)				256 us
AH/SHA1 (hw)				317 us
ESP/3DES,SHA1 (sw)			333 us
ESP/3DES,SHA1 (hw)			347 us
ESP-AH/3DES,SHA1-SHA1 (sw)		387 us
ESP-AH/3DES,SHA1-SHA1 (hw)		467 us

TCP Latency tests (1024 byte msg)

Config					Latency
No IPSEC				625 us
AH/SHA1 (sw)				771 us
AH/SHA1 (hw)				858 us
ESP/3DES,SHA1 (sw)			1999 us
ESP/3DES,SHA1 (hw)			902 us
ESP-AH/3DES,SHA1-SHA1 (sw)		2140 us
ESP-AH/3DES,SHA1-SHA1 (hw)		1131 us

Bandwidth tests

Config (sender -> receiver)		Bandwidth	ori CPU	  tank CPU
No IPSEC (tank->ori)			11494 KB/s	11.9%	  18.7%
No IPSEC (ori->tank)			11492 KB/s	9.5%	  34.3%

AH/SHA1 (sw) (tank->ori)		11303 KB/s	29.2%	  79.3%
AH/SHA1 (sw) (ori->tank)		11302 KB/s	28.6%	  91.1%
ESP/3DES,SHA1 (sw) (tank->ori)		2130 KB/s	29.6%	  100%
ESP/3DES,SHA1 (sw) (ori->tank)		2263 KB/s	29.3%	  99.7%
ESP-AH/3DES,SHA1-SHA1 (sw) (tank->ori)	1906 KB/s	29.1%	  100%
ESP-AH/3DES,SHA1-SHA1 (sw) (ori->tank)	2051 KB/s	29.3%	  99.7%

AH/SHA1 (hw) (tank->ori)		11303 KB/s	14.0%	  30.2%
AH/SHA1 (hw) (ori->tank)		11301 KB/s	14.1%	  39.8%
ESP/3DES,SHA1 (hw) (tank->ori)		11221 KB/s	15.4%	  44.9%
ESP/3DES,SHA1 (hw) (ori->tank)		11220 KB/s	21.5%	  48.1%
ESP-AH/3DES,SHA1-SHA1 (hw) (tank->ori)	5920 KB/s	10.8%	  35.9%
ESP-AH/3DES,SHA1-SHA1 (hw) (ori->tank)	7189 KB/s	14.3%	  35.4%


The last line seems suspicious, and should probably be retested.

             reply	other threads:[~2005-01-10 15:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-10 15:36 David Dillow [this message]
2005-01-10 15:36 ` [RFC BK 1/22] xfrm offload v2: Add direction information to xfrm_state David Dillow
2005-01-10 15:36   ` [RFC BK 2/22] xfrm offload v2: Add xfrm offload management calls to struct netdevice David Dillow
2005-01-10 15:36     ` [RFC BK 3/22] xfrm offload v2: Add offload management routines David Dillow
2005-01-10 15:36       ` [RFC BK 4/22] xfrm offload v2: Try to offload inbound xfrm_states David Dillow
2005-01-10 15:37         ` [RFC BK 5/22] xfrm offload v2: Attempt to offload bundled xfrm_states for outbound xfrms David Dillow
2005-01-10 15:37           ` [RFC BK 6/22] xfrm offload v2: add a parameter to xfrm_prune_bundles() David Dillow
2005-01-10 15:37             ` [RFC BK 7/22] xfrm offload v2: Allow device drivers to force recalculation of offloads David Dillow
2005-01-10 15:37               ` [RFC BK 8/22] xfrm offload v2: Add routines to manage applied offloads per skb David Dillow
2005-01-10 15:37                 ` [RFC BK 9/22] xfrm offload v2: Split AH header initialization from zeroing of mutable fields David Dillow
2005-01-10 15:37                   ` [RFC BK 10/22] xfrm offload v2: Add offloading of outbound AH & ESP packets David Dillow
2005-01-10 15:37                     ` [RFC BK 11/22] xfrm offload v2: Add offloading of inbound " David Dillow
2005-01-10 15:37                       ` [RFC BK 12/22] xfrm offload v2: Add ethtool support for crypto offload control David Dillow
2005-01-10 15:37                         ` [RFC BK 13/22] xfrm offload v2: typhoon: Make the ipsec descriptor match actual usage David Dillow
2005-01-10 15:37                           ` [RFC BK 14/22] xfrm offload v2: typhoon: add inbound offload result processing David Dillow
2005-01-10 15:37                             ` [RFC BK 15/22] xfrm offload v2: typhoon: add outbound offload processing David Dillow
2005-01-10 15:37                               ` [RFC BK 16/22] xfrm offload v2: typhoon: collect crypto offload capabilities David Dillow
2005-01-10 15:37                                 ` [RFC BK 17/22] xfrm offload v2: typhoon: split out setting of offloaded tasks David Dillow
2005-01-10 15:37                                   ` [RFC BK 18/22] xfrm offload v2: typhoon: add validation of offloaded xfrm_states David Dillow
2005-01-10 15:37                                     ` [RFC BK 19/22] xfrm offload v2: typhoon: add loading of xfrm_states to hardware David Dillow
2005-01-10 15:37                                       ` [RFC BK 20/22] xfrm offload v2: typhoon: add management of outbound bundles David Dillow
2005-01-10 15:37                                         ` [RFC BK 21/22] xfrm offload v2: typhoon: add callbacks to support crypto offload David Dillow
2005-01-10 15:37                                           ` [RFC BK 22/22] xfrm offload v2: Add some documentation for the IPSEC " David Dillow
2005-01-17 19:00 ` [RFC BK 0/22] xfrm offload v2: Add hardware assist for IPSEC crypto James Morris
2005-01-20 17:22   ` Dave Dillow

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=20040110014300.01@ori.thedillows.org \
    --to=dave@thedillows.org \
    --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).