lkml.org 
[lkml]   [2000]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: linux-ipsec: RE: [OFFTOPIC]Re: FW: Crypto: [PsuedoOfftopic]: Crypto Offload
Date
Not quite

The problem with having a library perform the operation and not kernel space
drivers is that it would require that you ship the buffer to be encrypted
over the PCI bus to the crypto accelerator, have it encrypt, ship it back
over the PCI bus to the library that would pass it on to the stack that
would ship it over the PCI bus to the NIC to go out on the wire...

While that is what you have to do for a generic hardware crypto accelerator,
I am talking about having the crypto accelerator on the NIC itself. What I
want to do is frame the packet, build a structure to pass to the nic Out of
Band (which is how at least Intel's NIC works) that tells the nic how to
apply security. Pass the whole packet over the PCI bus to the NIC, then
have the NIC encrypt (or decrypt) and spit it out the wire...

Doing this I can get around 80 Mbit/Sec throughput using about 1/2 of a
Celeron 500 processor on Win2K running IPsec, only doing software encryption
I can get about 12 Mbit/Sec using 100% of the same processor. YMMV

Bill
______________________________________________
Bill Strahm Programming today is a race between
bill.strahm@ software engineers striving to build
intel.com bigger and better idiot-proof programs,
(503) 264-4632 and the Universe trying to produce
bigger and better idiots. So far, the
Universe is winning.--Rich Cook
I am not speaking for Intel. And Intel rarely speaks for me


> -----Original Message-----
> From: Michael T. Babcock [mailto:mbabcock@fibrespeed.net]
> Sent: Tuesday, August 08, 2000 7:12 AM
> To: Strahm, Bill; 'Michael T. Babcock'
> Cc: linux-kernel@vger.rutgers.edu; linux-ipsec@clinet.fi
> Subject: Re: linux-ipsec: RE: [OFFTOPIC]Re: FW: Crypto:
> [PsuedoOfftopic]: Crypto Offload
>
>
> That would be the idea (more or less). After all, the kernel
> does not have
> a crypto API at all in comparison to OpenSSL and 'everyone'
> is using OpenSSL
> as their SSL, etc. library. An OpenCrypt library
> incorporating OpenSSL and
> mcrypt as well as mhash might be perfect for an
> all-crypto-API system which
> could then do the hooks to accelerator cards. The
> accelerator cards would
> have kernel drivers, but the library would do the offloading
> calls. There
> is no reason to kernel-space this work.
>
> ----- Original Message -----
> From: "Strahm, Bill" <bill.strahm@intel.com>
>
>
> > I do not see how Open SSL can perform this work. What
> needs to happen is
> an
> > inline offload processing. In otherwords, what I want to
> do is rather
> than
> > using Open SSL I want to go and pass information off to the
> NIC driver
> that
> > will tell the NIC to perform the crypto operation...
> >
> > I do not see how openSSL can help much with this, other
> than maybe write
> > something into SSL that says, if the NIC supports it, don't
> do crypto, but
> > when the packet goes out the wire, do the perscribed crypto
> operation
> > then...
>
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.635 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site