From: David Dillow <dave@thedillows.org>
To: netdev@oss.sgi.com
Cc: linux-kernel@vger.kernel.org, dave@thedillows.org
Subject: [RFC 2.6.10 0/22] Add hardware assist for IPSEC crypto
Date: Thu, 30 Dec 2004 03:48:34 -0500 [thread overview]
Message-ID: <20041230035000.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.
* 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.
* The use of GFP_ATOMIC in xfrm_offload_alloc() is probably not a good idea.
* 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.
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
It will update the following files:
Documentation/networking/netdevices.txt | 16
drivers/net/typhoon.c | 687 +++++++++++++++++++++++++++++++-
drivers/net/typhoon.h | 38 +
include/linux/ethtool.h | 8
include/linux/netdevice.h | 11
include/linux/skbuff.h | 55 ++
include/net/dst.h | 1
include/net/xfrm.h | 108 +++++
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 | 10
net/ipv6/xfrm6_state.c | 9
net/xfrm/xfrm_export.c | 4
net/xfrm/xfrm_policy.c | 64 ++
net/xfrm/xfrm_state.c | 101 ++++
17 files changed, 1284 insertions(+), 114 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.
next reply other threads:[~2004-12-30 8:48 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-30 8:48 David Dillow [this message]
2004-12-30 8:48 ` [RFC 2.6.10 1/22] xfrm: Add direction information to xfrm_state David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 2/22] xfrm: Add xfrm offload management calls to struct netdevice David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 3/22] xfrm: Add offload management routines David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 4/22] xfrm: Try to offload inbound xfrm_states David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 5/22] xfrm: Attempt to offload bundled xfrm_states for outbound xfrms David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 6/22] xfrm: add a parameter to xfrm_prune_bundles() David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 7/22] xfrm: Allow device drivers to force recalculation of offloads David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 8/22] skbuff: Add routines to manage applied offloads per skb David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 9/22] AH: Split header initialization from zeroing of mutable fields David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 10/22] AH, ESP: Add offloading of outbound packets David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 11/22] AH, ESP: Add offloading of inbound packets David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 12/22] ethtool: Add support for crypto offload David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 13/22] typhoon: Make the ipsec descriptor match actual usage David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 14/22] typhoon: add inbound offload result processing David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 15/22] typhoon: add outbound offload processing David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 16/22] typhoon: collect crypto offload capabilities David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 17/22] typhoon: split out setting of offloaded tasks David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 18/22] typhoon: add validation of offloaded xfrm_states David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 19/22] typhoon: add loading of xfrm_states to hardware David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 20/22] typhoon: add management of outbound bundles David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 21/22] typhoon: add callbacks to support crypto offload David Dillow
2004-12-30 8:48 ` [RFC 2.6.10 22/22] Add some documentation for the IPSEC " David Dillow
2005-01-21 23:23 ` [RFC 2.6.10 7/22] xfrm: Allow device drivers to force recalculation of offloads David S. Miller
2005-01-22 5:53 ` David Dillow
2005-01-26 6:11 ` David S. Miller
2005-01-21 23:21 ` [RFC 2.6.10 6/22] xfrm: add a parameter to xfrm_prune_bundles() David S. Miller
2004-12-30 23:34 ` [RFC 2.6.10 5/22] xfrm: Attempt to offload bundled xfrm_states for outbound xfrms Francois Romieu
2004-12-31 3:31 ` David Dillow
2005-01-21 23:20 ` David S. Miller
2005-01-22 5:53 ` David Dillow
2005-01-26 6:11 ` David S. Miller
2005-01-21 22:56 ` [RFC 2.6.10 4/22] xfrm: Try to offload inbound xfrm_states David S. Miller
2005-01-22 5:52 ` David Dillow
2005-01-26 6:13 ` David S. Miller
2005-01-21 22:47 ` [RFC 2.6.10 3/22] xfrm: Add offload management routines David S. Miller
2005-01-22 6:00 ` David Dillow
[not found] ` <1106373038.3691.39.camel@ori.thedillows.org>
[not found] ` <20050125221608.0cb067b2.davem@davemloft.net>
2005-01-26 21:30 ` David Dillow
2005-01-21 22:40 ` [RFC 2.6.10 2/22] xfrm: Add xfrm offload management calls to struct netdevice David S. Miller
2004-12-30 9:48 ` [RFC 2.6.10 1/22] xfrm: Add direction information to xfrm_state Jan-Benedict Glaw
2004-12-30 16:16 ` Dave Dillow
2004-12-30 16:36 ` Jan-Benedict Glaw
[not found] ` <200412301436.06653.ioe-lkml@axxeo.de>
2004-12-30 16:21 ` Dave Dillow
2005-01-21 22:38 ` David S. Miller
2005-01-22 5:50 ` David Dillow
2005-01-26 6:17 ` David S. Miller
2005-01-26 21:14 ` David Dillow
2005-01-21 22:35 ` [RFC 2.6.10 0/22] Add hardware assist for IPSEC crypto David S. Miller
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=20041230035000.01@ori.thedillows.org \
--to=dave@thedillows.org \
--cc=linux-kernel@vger.kernel.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).