Nicolas Williams wrote:
On Thu, Jul 23, 2009 at 05:34:13PM +1200, Peter Gutmann wrote:
"" <> writes:
2) If you throw TCP processing in there, unless you are consistantly going to
have packets on the order of at least 1000 bytes, your crypto algorithm is
almost _irrelevant_.
for a Linux 2.2.14 kernel, remember, this was 10 years ago.
Could the lack of support for TCP offload in Linux have skewed these figures
somewhat?  It could be that the caveat for the results isn't so much "this was
done ten years ago" as "this was done with a TCP stack that ignores the
hardware's advanced capabilities".

How much NIC hardware does both, ESP/AH and TCP offload?  My guess: not
much.  A shame, that.

Once you've gotten a packet off the NIC to do ESP/AH processing, you've
lost the opportunity to use TOE.

The SCA-4000 card from Sun provided the ESP/AH IPsec offload as well as a general purpose crypto acceleration. The ESP/AH wasn't able to deal with all cases (if I remember correctly some fragmented packet cases) so we still had to "punt" to software IPsec and use the hardware crypto on the same card to do the decrypt/mac. It turned out that in almost all cases we got better over all throughput of the machine (and ironically lower CPU utilisation as well) using the card as a hardware crypto accelerator rather than an IPsec offloader. This card didn't do TOE though because Solaris/OpenSolaris doesn't do TOE because we don't need it (and thus have no interfaces for it). This was 3DES, MD5, SHA1 era IPsec.

So when its successor came along, the SCA-6000 (adding AES), the NIC was dropped.

Darren J Moffat

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to