ocf-linux-users — Anything and everything ocf-linux related

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

[hiren j. <jos...@gm...>]

Any suggestion/comment/pointers on this  would be a great help.

Thanks.

Regards,
hiren

On Fri, Mar 6, 2009 at 12:02 PM, hiren joshi <jos...@gm...> wrote:
>>> 1. With OCF: Incorporate OCF glue in the existing driver I got with SDK.
>>> It will allow other sub-systems and applications to use the card.
>>> (As I have only one card, session migration is not relevant here.)
>>
>> Whatever you feel works the best.  Starting with an existing OCF driver
>> and swapping the API calls to the hifn API would seem easiest to me,
>> but that is your call.
>
> Thank you for suggesting this.
>
>>> 2. Without OCF: Native integration with Openswan (KLIPS) using the SDK APIs.
>>> This will help me to get full advantage of the card (protocol
>>> processing offloading).
>>
>> The overhead that OCF adds to the crypto process is very small.  I did
>> this test with the IXP driver (look at ocf-bench.c to see the IXP native
>> and OCF parts of the test).
>
> I should have been more wordy here.
> What I mean by protocol processing offloading is -
>
> besides crypto, compression and randomization,
> the 8155 (HIPP II family, DS-250/255 series) card supports
> following packet processing protocols:
>
> - IPSec - AH, ESP, Transport and Tunnel mode,
> - UDP encapsulation for NAT-T,
> - IKE,
> - SSL/TSL/DTLS,
> - Raw cryptographic transforms
>
> So I meant to use these features to completely offload
> the packet protocol processing (not just crypto operations)
> by integrating the HiFN APIs with Openswan(KLIPS).
>
>> There was almost no reduction in crypto speed (IIRC < 1%).  This
>> basically means that #1 above is the best choice,  and it saves you have
>> to do anything in the openswan code and also lets you accelerate openssl
>> and potentially other things.
>
> Considering the complete protocol processing offloading,
> I will have to find new hook points in KLIPS.
>
> Are there any efforts going on (OCF-2?) that let us use
> these new features of such cards?
>
> Thanks for your time.
>
> Regards
> hiren
>

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[David M. <Dav...@se...>]

Jivin Jonathan Fournier lays it down ...
> Kim Phillips wrote:
> > On Mon, 09 Mar 2009 15:14:14 -0400
> > Jonathan Fournier <jon...@wi...> wrote:
> > 
> >> Here's some info about each scenarios:
> >>
> >> OCF talitos: modules loaded ocf, cryptodev, cryptosoft, talitos (from
> >> OCF)
> > 
> > being inserted in that order?  if so, I believe crypto is not being
> > offloaded to h/w, because cryptosoft was inserted before talitos.  This
> > is something I already warned you about.
> 
> Not in that order, sorry for the confusion, I did load talitos before cryptosoft.
> 
> > 
> >> OCF talitos (no cryptosoft): modules loaded ocf, cryptodev, talitos
> >> (from OCF)
> > 
> > this looks like it's using the SEC h/w to do the crypto.  grep
> > talitos /proc/interrupts and the number should grow.
> > 
> >> CryptoAPI talitos: modules loaded ocf, cryptodev, cryptosoft, talitos
> >> (from CryptoAPI HW support)
> > 
> > here the crypto is being done in s/w, because the mainline CryptoAPI
> > talitos driver doesn't support straight ciphers.
> > 
> > You can tell what a driver supports by looking at the algorithms it
> > registers with.
> > 
> > Drivers that register successfully with the mainline's CryptoAPI will
> > also show up in /proc/crypto.
> > 
> >> Bare OCF cryptosoft: modules loaded ocf, cryptodev, cryptosoft, no HW
> >> driver loaded.
> > 
> > so s/w is doing the crypto.
> > 
> >> Bare openssl: no crypto framework loaded and bare openssl.
> > 
> > again s/w, this time using libssl's userspace version of the
> > algorithms.
> > 
> >> >From these numbers I can concluded that:
> >>
> >> For AES128
> >> * Bare openssl and cryptosoft performs better than with HW enabled.
> >> * The other bigger block size results are the same.
> > 
> > based on the above, I'd say you have the two mixed up - the h/w is
> > faster on the smaller packet sizes because of the offload benefit.
> > 
> > The larger packet sizes are neck-and-neck because at that point, the
> > overhead of offloading the crypto is masked because the crypto itself
> > has become the bottleneck.
> > 
> > David has patches for openssl that report CPU load during the crypto
> > run - you should see a significant drop in cpu load, esp. for those
> > large packet sizes.
> 
> These are part of the OCF-linux tarball? Somewhere on the project pages or 
> mailing archive? I don't think I've seen them.

Have a look in the ocf-linux-20080917.tar.gz:

	http://downloads.sourceforge.net/ocf-linux/ocf-linux-20080917.tar.gz

There are patches for various openssl versions,  they all have the
features Kim mentioned,

Cheers,
Davidm


> >> For 3DES:
> >> * Bare openssl and with OCF talitos without cryptosoft performs better
> >> for smaller blocks sizes (blocks < 256 bytes)
> >> * OCF/CrytoAPI talitos performs better from bigger block sizes.
> >> * The problem is that with cryptosoft without talitos modules loaded, I
> >> get the same results??
> >>
> >> I'm quite confused here, any comments on those numbers? ;)
> > 
> > see above on how to determine when the crypto is being done on the SEC
> > vs. the CPU core.
> > 
> > Kim
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
> 

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Jonathan F. <jon...@wi...>]

Kim Phillips wrote:
> On Mon, 09 Mar 2009 15:14:14 -0400
> Jonathan Fournier <jon...@wi...> wrote:
> 
>> Here's some info about each scenarios:
>>
>> OCF talitos: modules loaded ocf, cryptodev, cryptosoft, talitos (from
>> OCF)
> 
> being inserted in that order?  if so, I believe crypto is not being
> offloaded to h/w, because cryptosoft was inserted before talitos.  This
> is something I already warned you about.

Not in that order, sorry for the confusion, I did load talitos before cryptosoft.

> 
>> OCF talitos (no cryptosoft): modules loaded ocf, cryptodev, talitos
>> (from OCF)
> 
> this looks like it's using the SEC h/w to do the crypto.  grep
> talitos /proc/interrupts and the number should grow.
> 
>> CryptoAPI talitos: modules loaded ocf, cryptodev, cryptosoft, talitos
>> (from CryptoAPI HW support)
> 
> here the crypto is being done in s/w, because the mainline CryptoAPI
> talitos driver doesn't support straight ciphers.
> 
> You can tell what a driver supports by looking at the algorithms it
> registers with.
> 
> Drivers that register successfully with the mainline's CryptoAPI will
> also show up in /proc/crypto.
> 
>> Bare OCF cryptosoft: modules loaded ocf, cryptodev, cryptosoft, no HW
>> driver loaded.
> 
> so s/w is doing the crypto.
> 
>> Bare openssl: no crypto framework loaded and bare openssl.
> 
> again s/w, this time using libssl's userspace version of the
> algorithms.
> 
>> >From these numbers I can concluded that:
>>
>> For AES128
>> * Bare openssl and cryptosoft performs better than with HW enabled.
>> * The other bigger block size results are the same.
> 
> based on the above, I'd say you have the two mixed up - the h/w is
> faster on the smaller packet sizes because of the offload benefit.
> 
> The larger packet sizes are neck-and-neck because at that point, the
> overhead of offloading the crypto is masked because the crypto itself
> has become the bottleneck.
> 
> David has patches for openssl that report CPU load during the crypto
> run - you should see a significant drop in cpu load, esp. for those
> large packet sizes.

These are part of the OCF-linux tarball? Somewhere on the project pages or 
mailing archive? I don't think I've seen them.

Thanks for the useful debug commands!

Cheers,

/jonathan

> 
>> For 3DES:
>> * Bare openssl and with OCF talitos without cryptosoft performs better
>> for smaller blocks sizes (blocks < 256 bytes)
>> * OCF/CrytoAPI talitos performs better from bigger block sizes.
>> * The problem is that with cryptosoft without talitos modules loaded, I
>> get the same results??
>>
>> I'm quite confused here, any comments on those numbers? ;)
> 
> see above on how to determine when the crypto is being done on the SEC
> vs. the CPU core.
> 
> Kim

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Kim P. <kim...@fr...>]

On Mon, 09 Mar 2009 15:14:14 -0400
Jonathan Fournier <jon...@wi...> wrote:

> Here's some info about each scenarios:
> 
> OCF talitos: modules loaded ocf, cryptodev, cryptosoft, talitos (from
> OCF)

being inserted in that order?  if so, I believe crypto is not being
offloaded to h/w, because cryptosoft was inserted before talitos.  This
is something I already warned you about.

> OCF talitos (no cryptosoft): modules loaded ocf, cryptodev, talitos
> (from OCF)

this looks like it's using the SEC h/w to do the crypto.  grep
talitos /proc/interrupts and the number should grow.

> CryptoAPI talitos: modules loaded ocf, cryptodev, cryptosoft, talitos
> (from CryptoAPI HW support)

here the crypto is being done in s/w, because the mainline CryptoAPI
talitos driver doesn't support straight ciphers.

You can tell what a driver supports by looking at the algorithms it
registers with.

Drivers that register successfully with the mainline's CryptoAPI will
also show up in /proc/crypto.

> Bare OCF cryptosoft: modules loaded ocf, cryptodev, cryptosoft, no HW
> driver loaded.

so s/w is doing the crypto.

> Bare openssl: no crypto framework loaded and bare openssl.

again s/w, this time using libssl's userspace version of the
algorithms.

> >From these numbers I can concluded that:
> 
> For AES128
> * Bare openssl and cryptosoft performs better than with HW enabled.
> * The other bigger block size results are the same.

based on the above, I'd say you have the two mixed up - the h/w is
faster on the smaller packet sizes because of the offload benefit.

The larger packet sizes are neck-and-neck because at that point, the
overhead of offloading the crypto is masked because the crypto itself
has become the bottleneck.

David has patches for openssl that report CPU load during the crypto
run - you should see a significant drop in cpu load, esp. for those
large packet sizes.

> For 3DES:
> * Bare openssl and with OCF talitos without cryptosoft performs better
> for smaller blocks sizes (blocks < 256 bytes)
> * OCF/CrytoAPI talitos performs better from bigger block sizes.
> * The problem is that with cryptosoft without talitos modules loaded, I
> get the same results??
> 
> I'm quite confused here, any comments on those numbers? ;)

see above on how to determine when the crypto is being done on the SEC
vs. the CPU core.

Kim

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Jonathan F. <jon...@wi...>]

Hi Kim,

Regarding both async crypto framework, what should be the expected
results? Should I see a raw bytes per second processing improvements?
Purely main CPU cycles offloaded to the SEC chip without bytes/s
increase?

I ran "openssl speed" tests with various kernel configurations, and the
numbers look "weird" to me.

AES-128-CBC


    16 bytes
    64 bytes
   256 bytes
  1024 bytes
  2048 bytes
OCF talitos
      2180.2
     7156.01
    16981.85
    25897.64
     28349.1
OCF talitos
(no
cryptosoft)
    22046.78
    26210.58
    27987.97
    28476.76
     28553.9
CryptoAPI
talitos
      2173.1
     7151.13
    16913.58
    25863.85
    28369.58
Bare OCF
cryptosoft
     2151.89
     7114.11
    16884.48
    25802.41
    28311.55
Bare openssl
    22231.26
    26749.14
    28252.93
    28659.37
    28709.55

DES-EDE3-CBC


    16 bytes
    64 bytes
   256 bytes
  1024 bytes
  2048 bytes
OCF talitos
1801.58
3931.2
5580.2
6242.3
6369.96
OCF talitos
(no
cryptosoft)
4877.43
5101.7
5162.24
4732.03
5180.07
CryptoAPI
talitos
1807.41
3928.26
5579.78
6243.33
6367.91
Bare OCF
cryptosoft
1812.72
3933.72
5581.48
6242.99
6365.11
Bare openssl
4875.67
5102.17
5161.47
5177.34
5179.39

The 'numbers' are in 1000s of bytes per second processed.

Here's some info about each scenarios:

OCF talitos: modules loaded ocf, cryptodev, cryptosoft, talitos (from
OCF)

OCF talitos (no cryptosoft): modules loaded ocf, cryptodev, talitos
(from OCF)

CryptoAPI talitos: modules loaded ocf, cryptodev, cryptosoft, talitos
(from CryptoAPI HW support)

Bare OCF cryptosoft: modules loaded ocf, cryptodev, cryptosoft, no HW
driver loaded.

Bare openssl: no crypto framework loaded and bare openssl.

>From these numbers I can concluded that:

For AES128
* Bare openssl and cryptosoft performs better than with HW enabled.
* The other bigger block size results are the same.

For 3DES:
* Bare openssl and with OCF talitos without cryptosoft performs better
for smaller blocks sizes (blocks < 256 bytes)
* OCF/CrytoAPI talitos performs better from bigger block sizes.
* The problem is that with cryptosoft without talitos modules loaded, I
get the same results??

I'm quite confused here, any comments on those numbers? ;)

Cheers,

/jonathan


On Fri, 2009-03-06 at 15:57 -0600, Kim Phillips wrote:
> On Fri, 06 Mar 2009 16:13:51 -0500
> Jonathan Fournier <jon...@wi...> wrote:
> 
> > On Fri, 2009-03-06 at 15:17 -0600, Kim Phillips wrote:
> > > On Fri, 06 Mar 2009 13:25:57 -0500
> > > Jonathan Fournier <jon...@wi...> wrote:
> > > > Oh I didn't know that add support for public key ops (PKEU) was on the
> > > > TODO list, just saw it from the driver header.
> > > > 
> > > > I thought it did because when querying openssl with
> > > > 
> > > > % openssl engine -c
> > > > 
> > > > It was printing out the supported BSD cryptodev to be:
> > > > 
> > > > DSA RSA DH
> > > > 
> > > > What algorithm are supported on the 8548 so that I can validate that I
> > > > have the driver working properly?
> > > > 
> > > > I tried aes-128-cbc and got the same results with or without cryptodev
> > > > support, I assume I picked a wrong one randomly then? ;)
> > > 
> > > not sure (I haven't run OCF in a while), but aes was implemented and
> > > tested with IPSec.  I do recall having to insmod talitos prior to
> > > cryptosoft though, if that helps.
> > > 
> > 
> > Oh I didn't have cryptosoft loaded at the same time :( I thought they
> > were mutually exclusive, so I assume then that every HW drivers rely on
> > that layer?
> 
> It's more like cryptosoft is the "backup algorithm supplier" for
> algorithms the h/w driver does not implement.
> 
> > > Are you using crypto on the 8548 for something other than IPSec?  If
> > > not, is there a reason you're not using the mainline linux kernel
> > > driver?
> > 
> > I used the 8548 because I had access to a couple of Freescale SEC
> > enabled target in my lab.
> > 
> > For now I'm trying to get up to speed on both framework (OCF and
> > CryptoAPI) to see the pros and cons of each other, and what isn't
> > available yet to try to help on a project.
> > 
> > At the begining my high level requirements were:
> > 
> > * asynchronously perform encryption when a HW crypto engine is available
> > * asynchronously perform IPsec Authentication Header (AH) and
> > Encapsulating Security Protocol (ESP) encryption when an HW crypto
> > engine is available
> 
> both frameworks perform the above.
> 
> > * integration with openssl (cryptodev)
> 
> OCF does this "natively" today, but in conjunction with cryptosoft, OCF
> can be used as the interface between openssl and the mainline kernel
> drivers.
> 
> > I know there's some contribution coming from AMCC engineers related to
> > the cryptodev support with CryptoAPI, but I'm not fully up to speed on
> > that yet. What is that state of async support in CryptoAPI, in general
> > is the HW drivers are getting improved only in one of the two framework?
> 
> maintenance has shifted to the mainline driver due to reasons such as
> the above.
> 
> > Are they compatible?
> 
> not sure what you mean here.
> 
> Kim
--
Jonathan Fournier, Senior Engineer, Wind River
direct +1.613.270.5786  mobile +1.613.263.9223  fax +1.613.592.2283
350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5, Canada

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Kim P. <kim...@fr...>]

On Fri, 06 Mar 2009 16:13:51 -0500
Jonathan Fournier <jon...@wi...> wrote:

> On Fri, 2009-03-06 at 15:17 -0600, Kim Phillips wrote:
> > On Fri, 06 Mar 2009 13:25:57 -0500
> > Jonathan Fournier <jon...@wi...> wrote:
> > > Oh I didn't know that add support for public key ops (PKEU) was on the
> > > TODO list, just saw it from the driver header.
> > > 
> > > I thought it did because when querying openssl with
> > > 
> > > % openssl engine -c
> > > 
> > > It was printing out the supported BSD cryptodev to be:
> > > 
> > > DSA RSA DH
> > > 
> > > What algorithm are supported on the 8548 so that I can validate that I
> > > have the driver working properly?
> > > 
> > > I tried aes-128-cbc and got the same results with or without cryptodev
> > > support, I assume I picked a wrong one randomly then? ;)
> > 
> > not sure (I haven't run OCF in a while), but aes was implemented and
> > tested with IPSec.  I do recall having to insmod talitos prior to
> > cryptosoft though, if that helps.
> > 
> 
> Oh I didn't have cryptosoft loaded at the same time :( I thought they
> were mutually exclusive, so I assume then that every HW drivers rely on
> that layer?

It's more like cryptosoft is the "backup algorithm supplier" for
algorithms the h/w driver does not implement.

> > Are you using crypto on the 8548 for something other than IPSec?  If
> > not, is there a reason you're not using the mainline linux kernel
> > driver?
> 
> I used the 8548 because I had access to a couple of Freescale SEC
> enabled target in my lab.
> 
> For now I'm trying to get up to speed on both framework (OCF and
> CryptoAPI) to see the pros and cons of each other, and what isn't
> available yet to try to help on a project.
> 
> At the begining my high level requirements were:
> 
> * asynchronously perform encryption when a HW crypto engine is available
> * asynchronously perform IPsec Authentication Header (AH) and
> Encapsulating Security Protocol (ESP) encryption when an HW crypto
> engine is available

both frameworks perform the above.

> * integration with openssl (cryptodev)

OCF does this "natively" today, but in conjunction with cryptosoft, OCF
can be used as the interface between openssl and the mainline kernel
drivers.

> I know there's some contribution coming from AMCC engineers related to
> the cryptodev support with CryptoAPI, but I'm not fully up to speed on
> that yet. What is that state of async support in CryptoAPI, in general
> is the HW drivers are getting improved only in one of the two framework?

maintenance has shifted to the mainline driver due to reasons such as
the above.

> Are they compatible?

not sure what you mean here.

Kim

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Jonathan F. <jon...@wi...>]

On Fri, 2009-03-06 at 15:17 -0600, Kim Phillips wrote:
> On Fri, 06 Mar 2009 13:25:57 -0500
> Jonathan Fournier <jon...@wi...> wrote:
> > Oh I didn't know that add support for public key ops (PKEU) was on the
> > TODO list, just saw it from the driver header.
> > 
> > I thought it did because when querying openssl with
> > 
> > % openssl engine -c
> > 
> > It was printing out the supported BSD cryptodev to be:
> > 
> > DSA RSA DH
> > 
> > What algorithm are supported on the 8548 so that I can validate that I
> > have the driver working properly?
> > 
> > I tried aes-128-cbc and got the same results with or without cryptodev
> > support, I assume I picked a wrong one randomly then? ;)
> 
> not sure (I haven't run OCF in a while), but aes was implemented and
> tested with IPSec.  I do recall having to insmod talitos prior to
> cryptosoft though, if that helps.
> 

Oh I didn't have cryptosoft loaded at the same time :( I thought they
were mutually exclusive, so I assume then that every HW drivers rely on
that layer?

> Are you using crypto on the 8548 for something other than IPSec?  If
> not, is there a reason you're not using the mainline linux kernel
> driver?

I used the 8548 because I had access to a couple of Freescale SEC
enabled target in my lab.

For now I'm trying to get up to speed on both framework (OCF and
CryptoAPI) to see the pros and cons of each other, and what isn't
available yet to try to help on a project.

At the begining my high level requirements were:

* asynchronously perform encryption when a HW crypto engine is available
* asynchronously perform IPsec Authentication Header (AH) and
Encapsulating Security Protocol (ESP) encryption when an HW crypto
engine is available
* integration with openssl (cryptodev)

I know there's some contribution coming from AMCC engineers related to
the cryptodev support with CryptoAPI, but I'm not fully up to speed on
that yet. What is that state of async support in CryptoAPI, in general
is the HW drivers are getting improved only in one of the two framework?
Are they compatible?

Cheers,

/jonathan

> 
> Kim
--
Jonathan Fournier, Senior Engineer, Wind River
direct +1.613.270.5786  mobile +1.613.263.9223  fax +1.613.592.2283
350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5, Canada

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Kim P. <kim...@fr...>]

On Fri, 06 Mar 2009 13:25:57 -0500
Jonathan Fournier <jon...@wi...> wrote:
> Oh I didn't know that add support for public key ops (PKEU) was on the
> TODO list, just saw it from the driver header.
> 
> I thought it did because when querying openssl with
> 
> % openssl engine -c
> 
> It was printing out the supported BSD cryptodev to be:
> 
> DSA RSA DH
> 
> What algorithm are supported on the 8548 so that I can validate that I
> have the driver working properly?
> 
> I tried aes-128-cbc and got the same results with or without cryptodev
> support, I assume I picked a wrong one randomly then? ;)

not sure (I haven't run OCF in a while), but aes was implemented and
tested with IPSec.  I do recall having to insmod talitos prior to
cryptosoft though, if that helps.

Are you using crypto on the 8548 for something other than IPSec?  If
not, is there a reason you're not using the mainline linux kernel
driver?

Kim

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Jonathan F. <jon...@wi...>]

All these (in the debug output) ioctl errno code 22 means Invalid
argument like returned by the cryptotest tool in verbose mode.

Something seems wrong at opening these CIOCGSESSION.

Cheers,

/jonathan

On Fri, 2009-03-06 at 10:24 -0500, Jonathan Fournier wrote:
> Forgot to CC list sorry.
> 
> -------- Forwarded Message --------
> > From: Jonathan Fournier <jon...@wi...>
> > To: dav...@se...
> > Subject: Re: OCF-linux and 2.6.27.x
> > Date: Thu, 05 Mar 2009 14:39:59 -0500
> > 
> > I suspect things that might be going wrong here, I don't know if it's
> > related to 2.6.27 or something.
> > 
> > I'm using a Freescale 8548 (talitos.ko with debug enabled)
> > 
> > % cryptotest -v 100 4096
> >  crid = 3000000
> > cipher 3des keylen 24
> > CIOCGSESSION: Invalid argument
> > root@sbc8548:/root> Jan  1 02:38:06 sbc8548 kernel: cryptodev_open()
> > Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(cmd=c0046364 arg=b8faf438)
> > Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CRIOGET)
> > Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(cmd=c030636a arg=b8faf43c)
> > Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION2)
> > Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION2) - no mac
> > Jan  1 02:38:06 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,370: DRIVER_LOCK()
> > Jan  1 02:38:06 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,406: DRIVER_UNLOCK()
> > Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION2) - newsession 22
> > Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION2) - bail 22
> > Jan  1 02:38:06 sbc8548 kernel: cryptodev_release()
> > 
> > The crypto-tools seems to fail with CIOCGSESSION: Invalid argument.
> > 
> > % openssl engine -c
> > (cryptodev) BSD cryptodev engine
> >  [RSA, DSA, DH]
> > (dynamic) Dynamic engine loading support
> > root@sbc8548:/root> Jan  1 02:43:21 sbc8548 kernel: cryptodev_open()
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c0046364 arg=bccc5828)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CRIOGET)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=40046369 arg=f77c910)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCASYMFEAT)
> > Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,1221: DRIVER_LOCK()
> > Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,1233: DRIVER_UNLOCK()
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c0046364 arg=bccc5758)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CRIOGET)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c01c6365 arg=bccc5780)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - no mac
> > Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,370: DRIVER_LOCK()
> > Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,406: DRIVER_UNLOCK()
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - newsession 22
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - bail 22
> > ... repeated 5 times
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c0046364 arg=bccc5758)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CRIOGET)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c01c6365 arg=bccc5780)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION)
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - no cipher
> > Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,370: DRIVER_LOCK()
> > Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,406: DRIVER_UNLOCK()
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - newsession 22
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - bail 22
> > ... repeated 4 times
> > 
> > Then it does repeat the whole "no mac", "no cipher" a second time and then exit with:
> > 
> > Jan  1 02:43:21 sbc8548 kernel: cryptodev_release()
> > 
> > I don't get any kernel crashing error or something, but with openssl
> > having BSD cryptodev engine present or not doesn't change anything, I
> > always get the same "openssl speed -engine cryptodev dsa -elapsed"
> > benchmark results in both cases.
> > 
> > Do you have any idea?
> > 
> > Cheers,
> > 
> > /jonathan
> > 
> > On Thu, 2009-03-05 at 13:09 -0500, Jonathan Fournier wrote:
> > > Hi David,
> > > 
> > > I recently tried OCF-linux and Linux 2.6.27.18 and got minor compile
> > > errors.
> > > 
> > > I saw that the OpenWrt folks had this fix to overcome kill_proc to use
> > > send_sig:
> > > 
> > > https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.27/973-ocf_2.6.27_fix.patch?rev=13341
> > > 
> > > And that files_fdtable usage now requires:
> > > 
> > > diff --git a/crypto/ocf/cryptodev.c b/crypto/ocf/cryptodev.c
> > > index 13d57a1..5110447 100644
> > > --- a/crypto/ocf/cryptodev.c
> > > +++ b/crypto/ocf/cryptodev.c
> > > @@ -58,6 +58,7 @@ __FBSDID("$FreeBSD: src/sys/opencrypto/cryptodev.c,v 1.34 2007/05/09 19:37:02 gn
> > >  #include <linux/mount.h>
> > >  #include <linux/miscdevice.h>
> > >  #include <linux/version.h>
> > > +#include <linux/fdtable.h>
> > >  #include <asm/uaccess.h>
> > > 
> > >  #include <cryptodev.h>
> > > 
> > > 
> > > Is the "experimental" fix for kill_proc make sens to you to include in
> > > newer OCF-linux release?
> > > 
> > > I also have other questings regarding the TODO list:
> > > 
> > > * What are the preemption problems under 2.6? I'm interested in helping
> > > fixing them if it still applies.
> > > 
> > > * About the Full IPSEC payload processing, do you mean integration with
> > > the native Linux IPSEC stack, or continue with OpenSWAN KLIPS? Which one
> > > is preferable?
> > > 
> > > * What is your general feeling about the other initiative with Linux
> > > CryptoAPI? I saw some threads from this Spring/Summer, that another
> > > similar cryptodev-like interface is being created?
> > > 
> > > From:
> > > http://marc.info/?l=openssl-users&m=121941527119483&w=2
> > > http://www.mail-archive.com/lin...@vg.../msg01908.html
> > > http://www.mail-archive.com/lin...@vg.../msg02172.html
> > > http://www.mail-archive.com/lin...@vg.../msg02234.html
> > > 
> > > Cheers,
> > > 
> > > --
> > > Jonathan Fournier, Senior Engineer, Wind River
> > > direct +1.613.270.5786  mobile +1.613.263.9223  fax +1.613.592.2283
> > > 350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5, Canada
> 
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
--
Jonathan Fournier, Senior Engineer, Wind River
direct +1.613.270.5786  mobile +1.613.263.9223  fax +1.613.592.2283
350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5, Canada

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Jonathan F. <jon...@wi...>]

On Fri, 2009-03-06 at 11:32 -0600, Kim Phillips wrote:
> On Fri, 06 Mar 2009 10:24:18 -0500
> Jonathan Fournier <jon...@wi...> wrote:
>  
> > > I don't get any kernel crashing error or something, but with openssl
> > > having BSD cryptodev engine present or not doesn't change anything, I
> > > always get the same "openssl speed -engine cryptodev dsa -elapsed"
> > > benchmark results in both cases.
> > > 
> > > Do you have any idea?
> 
> the driver doesn't implement dsa?

Oh I didn't know that add support for public key ops (PKEU) was on the
TODO list, just saw it from the driver header.

I thought it did because when querying openssl with

% openssl engine -c

It was printing out the supported BSD cryptodev to be:

DSA RSA DH

What algorithm are supported on the 8548 so that I can validate that I
have the driver working properly?

I tried aes-128-cbc and got the same results with or without cryptodev
support, I assume I picked a wrong one randomly then? ;)

Cheers,

/jonathan

> 
> Kim

Re: [Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Kim P. <kim...@fr...>]

On Fri, 06 Mar 2009 10:24:18 -0500
Jonathan Fournier <jon...@wi...> wrote:
 
> > I don't get any kernel crashing error or something, but with openssl
> > having BSD cryptodev engine present or not doesn't change anything, I
> > always get the same "openssl speed -engine cryptodev dsa -elapsed"
> > benchmark results in both cases.
> > 
> > Do you have any idea?

the driver doesn't implement dsa?

Kim

[Ocf-linux-users] [Fwd: Re: OCF-linux and 2.6.27.x]

[Jonathan F. <jon...@wi...>]

Forgot to CC list sorry.

-------- Forwarded Message --------
> From: Jonathan Fournier <jon...@wi...>
> To: dav...@se...
> Subject: Re: OCF-linux and 2.6.27.x
> Date: Thu, 05 Mar 2009 14:39:59 -0500
> 
> I suspect things that might be going wrong here, I don't know if it's
> related to 2.6.27 or something.
> 
> I'm using a Freescale 8548 (talitos.ko with debug enabled)
> 
> % cryptotest -v 100 4096
>  crid = 3000000
> cipher 3des keylen 24
> CIOCGSESSION: Invalid argument
> root@sbc8548:/root> Jan  1 02:38:06 sbc8548 kernel: cryptodev_open()
> Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(cmd=c0046364 arg=b8faf438)
> Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CRIOGET)
> Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(cmd=c030636a arg=b8faf43c)
> Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION2)
> Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION2) - no mac
> Jan  1 02:38:06 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,370: DRIVER_LOCK()
> Jan  1 02:38:06 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,406: DRIVER_UNLOCK()
> Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION2) - newsession 22
> Jan  1 02:38:06 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION2) - bail 22
> Jan  1 02:38:06 sbc8548 kernel: cryptodev_release()
> 
> The crypto-tools seems to fail with CIOCGSESSION: Invalid argument.
> 
> % openssl engine -c
> (cryptodev) BSD cryptodev engine
>  [RSA, DSA, DH]
> (dynamic) Dynamic engine loading support
> root@sbc8548:/root> Jan  1 02:43:21 sbc8548 kernel: cryptodev_open()
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c0046364 arg=bccc5828)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CRIOGET)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=40046369 arg=f77c910)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCASYMFEAT)
> Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,1221: DRIVER_LOCK()
> Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,1233: DRIVER_UNLOCK()
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c0046364 arg=bccc5758)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CRIOGET)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c01c6365 arg=bccc5780)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - no mac
> Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,370: DRIVER_LOCK()
> Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,406: DRIVER_UNLOCK()
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - newsession 22
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - bail 22
> ... repeated 5 times
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c0046364 arg=bccc5758)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CRIOGET)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(cmd=c01c6365 arg=bccc5780)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION)
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - no cipher
> Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,370: DRIVER_LOCK()
> Jan  1 02:43:21 sbc8548 kernel: /home/jfournie/sandbox/build-3.0/wrs_sbc8548/build/linux/crypto/ocf/crypto.c,406: DRIVER_UNLOCK()
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - newsession 22
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_ioctl(CIOCGSESSION) - bail 22
> ... repeated 4 times
> 
> Then it does repeat the whole "no mac", "no cipher" a second time and then exit with:
> 
> Jan  1 02:43:21 sbc8548 kernel: cryptodev_release()
> 
> I don't get any kernel crashing error or something, but with openssl
> having BSD cryptodev engine present or not doesn't change anything, I
> always get the same "openssl speed -engine cryptodev dsa -elapsed"
> benchmark results in both cases.
> 
> Do you have any idea?
> 
> Cheers,
> 
> /jonathan
> 
> On Thu, 2009-03-05 at 13:09 -0500, Jonathan Fournier wrote:
> > Hi David,
> > 
> > I recently tried OCF-linux and Linux 2.6.27.18 and got minor compile
> > errors.
> > 
> > I saw that the OpenWrt folks had this fix to overcome kill_proc to use
> > send_sig:
> > 
> > https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.27/973-ocf_2.6.27_fix.patch?rev=13341
> > 
> > And that files_fdtable usage now requires:
> > 
> > diff --git a/crypto/ocf/cryptodev.c b/crypto/ocf/cryptodev.c
> > index 13d57a1..5110447 100644
> > --- a/crypto/ocf/cryptodev.c
> > +++ b/crypto/ocf/cryptodev.c
> > @@ -58,6 +58,7 @@ __FBSDID("$FreeBSD: src/sys/opencrypto/cryptodev.c,v 1.34 2007/05/09 19:37:02 gn
> >  #include <linux/mount.h>
> >  #include <linux/miscdevice.h>
> >  #include <linux/version.h>
> > +#include <linux/fdtable.h>
> >  #include <asm/uaccess.h>
> > 
> >  #include <cryptodev.h>
> > 
> > 
> > Is the "experimental" fix for kill_proc make sens to you to include in
> > newer OCF-linux release?
> > 
> > I also have other questings regarding the TODO list:
> > 
> > * What are the preemption problems under 2.6? I'm interested in helping
> > fixing them if it still applies.
> > 
> > * About the Full IPSEC payload processing, do you mean integration with
> > the native Linux IPSEC stack, or continue with OpenSWAN KLIPS? Which one
> > is preferable?
> > 
> > * What is your general feeling about the other initiative with Linux
> > CryptoAPI? I saw some threads from this Spring/Summer, that another
> > similar cryptodev-like interface is being created?
> > 
> > From:
> > http://marc.info/?l=openssl-users&m=121941527119483&w=2
> > http://www.mail-archive.com/lin...@vg.../msg01908.html
> > http://www.mail-archive.com/lin...@vg.../msg02172.html
> > http://www.mail-archive.com/lin...@vg.../msg02234.html
> > 
> > Cheers,
> > 
> > --
> > Jonathan Fournier, Senior Engineer, Wind River
> > direct +1.613.270.5786  mobile +1.613.263.9223  fax +1.613.592.2283
> > 350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5, Canada

[Ocf-linux-users] [Fwd: OCF-linux and 2.6.27.x]

[Jonathan F. <jon...@wi...>]

Forgot to CC the list ;)

-------- Forwarded Message --------
> From: Jonathan Fournier <jon...@wi...>
> To: dav...@se...
> Subject: OCF-linux and 2.6.27.x
> Date: Thu, 05 Mar 2009 13:09:59 -0500
> 
> Hi David,
> 
> I recently tried OCF-linux and Linux 2.6.27.18 and got minor compile
> errors.
> 
> I saw that the OpenWrt folks had this fix to overcome kill_proc to use
> send_sig:
> 
> https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.27/973-ocf_2.6.27_fix.patch?rev=13341
> 
> And that files_fdtable usage now requires:
> 
> diff --git a/crypto/ocf/cryptodev.c b/crypto/ocf/cryptodev.c
> index 13d57a1..5110447 100644
> --- a/crypto/ocf/cryptodev.c
> +++ b/crypto/ocf/cryptodev.c
> @@ -58,6 +58,7 @@ __FBSDID("$FreeBSD: src/sys/opencrypto/cryptodev.c,v 1.34 2007/05/09 19:37:02 gn
>  #include <linux/mount.h>
>  #include <linux/miscdevice.h>
>  #include <linux/version.h>
> +#include <linux/fdtable.h>
>  #include <asm/uaccess.h>
> 
>  #include <cryptodev.h>
> 
> 
> Is the "experimental" fix for kill_proc make sense to you to include in
> newer OCF-linux release?
> 
> I also have other questings regarding the TODO list:
> 
> * What are the preemption problems under 2.6? I'm interested in helping
> fixing them if it still applies.
> 
> * About the Full IPSEC payload processing, do you mean integration with
> the native Linux IPSEC stack, or continue with OpenSWAN KLIPS? Which one
> is preferable?
> 
> * What is your general feeling about the other initiative with Linux
> CryptoAPI? I saw some threads from this Spring/Summer, that another
> similar cryptodev-like interface is being created?
> 
> From:
> http://marc.info/?l=openssl-users&m=121941527119483&w=2
> http://www.mail-archive.com/lin...@vg.../msg01908.html
> http://www.mail-archive.com/lin...@vg.../msg02172.html
> http://www.mail-archive.com/lin...@vg.../msg02234.html
> 
> Cheers,
> 
> --
> Jonathan Fournier, Senior Engineer, Wind River
> direct +1.613.270.5786  mobile +1.613.263.9223  fax +1.613.592.2283
> 350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5, Canada

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

[hiren j. <jos...@gm...>]

>> 1. With OCF: Incorporate OCF glue in the existing driver I got with SDK.
>> It will allow other sub-systems and applications to use the card.
>> (As I have only one card, session migration is not relevant here.)
>
> Whatever you feel works the best.  Starting with an existing OCF driver
> and swapping the API calls to the hifn API would seem easiest to me,
> but that is your call.

Thank you for suggesting this.

>> 2. Without OCF: Native integration with Openswan (KLIPS) using the SDK APIs.
>> This will help me to get full advantage of the card (protocol
>> processing offloading).
>
> The overhead that OCF adds to the crypto process is very small.  I did
> this test with the IXP driver (look at ocf-bench.c to see the IXP native
> and OCF parts of the test).

I should have been more wordy here.
What I mean by protocol processing offloading is -

besides crypto, compression and randomization,
the 8155 (HIPP II family, DS-250/255 series) card supports
following packet processing protocols:

- IPSec - AH, ESP, Transport and Tunnel mode,
- UDP encapsulation for NAT-T,
- IKE,
- SSL/TSL/DTLS,
- Raw cryptographic transforms

So I meant to use these features to completely offload
the packet protocol processing (not just crypto operations)
by integrating the HiFN APIs with Openswan(KLIPS).

> There was almost no reduction in crypto speed (IIRC < 1%).  This
> basically means that #1 above is the best choice,  and it saves you have
> to do anything in the openswan code and also lets you accelerate openssl
> and potentially other things.

Considering the complete protocol processing offloading,
I will have to find new hook points in KLIPS.

Are there any efforts going on (OCF-2?) that let us use
these new features of such cards?

Thanks for your time.

Regards
hiren

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

[David M. <Dav...@se...>]

Jivin hiren joshi lays it down ...
> Hello,
> 
> Thank you for the answer.
> 
> > I think you need to get the appropriate "devkit" from hifn, then write a
> > driver somewhat along the lines of either ixp4xx driver or the ep80579
> > driver that also rely on externally provided devkits.
> 
> Yes, I am having the SDK.
> 
> > It is usually a much simpler task to support such devices at they have a
> > nice API etc and you do not need to write a full HW driver.
> 
> I can think of two ways, and request you to comment on them.
> 
> 1. With OCF: Incorporate OCF glue in the existing driver I got with SDK.
> It will allow other sub-systems and applications to use the card.
> (As I have only one card, session migration is not relevant here.)

Whatever you feel works the best.  Starting with an existing OCF driver
and swapping the API calls to the hifn API would seem easiest to me,
but that is your call.

> 2. Without OCF: Native integration with Openswan (KLIPS) using the SDK APIs.
> This will help me to get full advantage of the card (protocol
> processing offloading).

The overhead that OCF adds to the crypto process is very small.  I did
this test with the IXP driver (look at ocf-bench.c to see the IXP native
and OCF parts of the test).

There was almost no reduction in crypto speed (IIRC < 1%).  This
basically means that #1 above is the best choice,  and it saves you have
to do anything in the openswan code and also lets you accelerate openssl
and potentially other things.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

[hiren j. <jos...@gm...>]

Hello,

Thank you for the answer.

> I think you need to get the appropriate "devkit" from hifn, then write a
> driver somewhat along the lines of either ixp4xx driver or the ep80579
> driver that also rely on externally provided devkits.

Yes, I am having the SDK.

> It is usually a much simpler task to support such devices at they have a
> nice API etc and you do not need to write a full HW driver.

I can think of two ways, and request you to comment on them.

1. With OCF: Incorporate OCF glue in the existing driver I got with SDK.
It will allow other sub-systems and applications to use the card.
(As I have only one card, session migration is not relevant here.)

2. Without OCF: Native integration with Openswan (KLIPS) using the SDK APIs.
This will help me to get full advantage of the card (protocol
processing offloading).

Regards,
hiren

Re: [Ocf-linux-users] help on how to use OCF for SSL v3.0 protocol's cryptographic operations

[lakshmi p. <lak...@fr...>]

Hi,

I am using OCF ixp4 crypto driver. The problem is present with cryptosoft also.
I guess I am passing wrong data to OCF to compute the MAC, can anyone 
tell me what is the correct data that is to be passed to the driver 
for SSLv3.0 protocol.

thanks,
Lakshmi Prasanna

At 06:19 AM 3/6/2009, David McCullough wrote:
>Jivin lakshmi prasanna lays it down ...
> > Hi,
> >
> > I am using OCF's ixp driver for Cryptographic operations.
> > TLS protocol is working fine, since it uses only a single
> > Authentication operation to be performed.
>
>
>You probably want to move this to the ocf-linux mailing list:
>
>     http://lists.sourceforge.net/mailman/listinfo/ocf-linux-users
>
> > Since SSL v3.0 protocol needs two rounds of operations to be
> > performed to calculate the MAC, I am calling OCF crypto_dispatch()
> > twice with the relevant data.
> > Since I am using SHA, 40 bytes of 0x36 and 0x5c pads are used
> >
> > Round 1 : HMAC(Initial seed+data)
> > Initial seed = Client_write_mac_secret+40 bytes of 0x36+sequence
> > number+application type(0x17)+data length
> >
> > Round 2: HMAC(Final Seed+result of Round 1)
> > Final Seed = Client_write_mac_secret+40 bytes of 0x5C
> >
> > The calculated MAC is different from the client generated MAC.
> >
> > Can anyone help me with what data to be passed to the OCF, the seeds
> > to be used for SSLv3.0, and other required data.
> >
> > I have gone through the SSLv3.0 draft, and surely I'm passing the
> > right seeds and offsets to the OCF, still the thing does not work...
> > May be I'm missing out something....
> > Please help......
>
>Which OCF crypto driver are you using ?  Talitos or cryptosoft or
>something else ?
>
>Cheers,
>Davidm
>
>--
>David McCullough,  dav...@se...,  Ph:+61 734352815
>McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org


thanks,
Lakshmi Prasanna 

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

[David M. <Dav...@se...>]

Jivin hiren joshi lays it down ...
> Hello,
> 
> I am having a HiFN Xcellerator Card 8155HXL-G (DS250 - DS255 series).
> I want to use this card with Openswan/KLIPS via OCF.
> 
> >From ocf-linux-20080917/ocf/ChangeLog,
> 
> 2007-07-25 21:25  davidm
> 
>         * Makefile, hifn/Makefile, hifn/hifnHIPP.c, hifn/hifnHIPPreg.h,
>         hifn/hifnHIPPvar.h, ixp4xx/Makefile, ocfnull/Makefile,
>         safe/Makefile, talitos/Makefile:
> 
>         Bring in the hifnHIPP driver written by Xelerance.  This is the
>         super hifn chip with full protocol offload.
> 
> So I think my card - 8155 (which belongs to HIPP-I/II family) is supported.
> 
> However I noted that in the HIPP driver file
> (ocf-linux-20080917/ocf/hifn/hifnHIPP.c),
> the call to crypto_register is commented out:
> 
> #if 0 /* no code here yet ?? */
> 	crypto_register(sc->sc_cid, CRYPTO_3DES_CBC, 0, 0);
> #endif
> 
> Also, the callback functions hipp_newsession, hipp_process and
> hipp_freesession just return EINVAL, and there is no crypto_done, crypto_kdone.
> 
> So I am just curious about the state of this driver.

Sadly, there is no 8155 or compatible driver.  This is just a left over
of something that never eventuated IIRC.

> Please guide me about how should I approach to use this card with OCF
> for Openswan.

I think you need to get the appropriate "devkit" from hifn, then write a
driver somewhat along the lines of either ixp4xx driver or the ep80579
driver that also rely on externally provided devkits.

It is usually a much simpler task to support such devices at they have a
nice API etc and you do not need to write a full HW driver.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] help on how to use OCF for SSL v3.0 protocol's cryptographic operations

[David M. <Dav...@se...>]

Jivin lakshmi prasanna lays it down ...
> Hi,
> 
> I am using OCF's ixp driver for Cryptographic operations.
> TLS protocol is working fine, since it uses only a single 
> Authentication operation to be performed.


You probably want to move this to the ocf-linux mailing list:

    http://lists.sourceforge.net/mailman/listinfo/ocf-linux-users

> Since SSL v3.0 protocol needs two rounds of operations to be 
> performed to calculate the MAC, I am calling OCF crypto_dispatch() 
> twice with the relevant data.
> Since I am using SHA, 40 bytes of 0x36 and 0x5c pads are used
> 
> Round 1 : HMAC(Initial seed+data)
> Initial seed = Client_write_mac_secret+40 bytes of 0x36+sequence 
> number+application type(0x17)+data length
> 
> Round 2: HMAC(Final Seed+result of Round 1)
> Final Seed = Client_write_mac_secret+40 bytes of 0x5C
> 
> The calculated MAC is different from the client generated MAC.
> 
> Can anyone help me with what data to be passed to the OCF, the seeds 
> to be used for SSLv3.0, and other required data.
> 
> I have gone through the SSLv3.0 draft, and surely I'm passing the 
> right seeds and offsets to the OCF, still the thing does not work...
> May be I'm missing out something....
> Please help......

Which OCF crypto driver are you using ?  Talitos or cryptosoft or
something else ?

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

[Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

[hiren j. <jos...@gm...>]

Hello,

I am having a HiFN Xcellerator Card 8155HXL-G (DS250 - DS255 series).
I want to use this card with Openswan/KLIPS via OCF.

>From ocf-linux-20080917/ocf/ChangeLog,

2007-07-25 21:25  davidm

        * Makefile, hifn/Makefile, hifn/hifnHIPP.c, hifn/hifnHIPPreg.h,
        hifn/hifnHIPPvar.h, ixp4xx/Makefile, ocfnull/Makefile,
        safe/Makefile, talitos/Makefile:

        Bring in the hifnHIPP driver written by Xelerance.  This is the
        super hifn chip with full protocol offload.

So I think my card - 8155 (which belongs to HIPP-I/II family) is supported.

However I noted that in the HIPP driver file
(ocf-linux-20080917/ocf/hifn/hifnHIPP.c),
the call to crypto_register is commented out:

#if 0 /* no code here yet ?? */
	crypto_register(sc->sc_cid, CRYPTO_3DES_CBC, 0, 0);
#endif

Also, the callback functions hipp_newsession, hipp_process and
hipp_freesession just return EINVAL, and there is no crypto_done, crypto_kdone.

So I am just curious about the state of this driver.

Please guide me about how should I approach to use this card with OCF
for Openswan.

Thanks for your time.

Regards,
hiren

Re: [Ocf-linux-users] Make sure HW crypto driver is loaded before cryptosoft

[Hector P. <hec...@di...>]

David McCullough wrote:
> You could try changing the "module_init" in cryptosoft to be "late_initcall",
> try this patch, not sure if it will work or not :-)

Hey, that did the trick. It works fine. Thank you.
-- 
Héctor Palacios

Re: [Ocf-linux-users] Make sure HW crypto driver is loaded before cryptosoft

[David M. <Dav...@se...>]

Jivin Hector Palacios lays it down ...
> Hi,
> 
> For HW acceleration to work, the kernel crypto driver must be loaded 
> *before* the cryptosoft module is loaded.
> When building these as loadable modules, it is just a question of 
> loading the modules in the correct order:
> modprobe <hw-driver>
> modprobe cryptosoft
> modprobe cryptodev
> 
> Now, if I want to have these as built-in features instead of loadable 
> modules, how can I guarantee that <hw-driver> is loaded before 
> cryptosoft? My driver is a platform device and it is currently being 
> probed *after* the kernel has loaded the cryptosoft, so it is not 
> working (OCF doesn't know about my driver).

You could try changing the "module_init" in cryptosoft to be "late_initcall",
try this patch, not sure if it will work or not :-)

Cheers,
Davidm

Index: ocf/cryptosoft.c
===================================================================
RCS file: /cvs/sw/new-wave/modules/ocf/cryptosoft.c,v
retrieving revision 1.40
diff -u -r1.40 cryptosoft.c
--- ocf/cryptosoft.c	19 Jan 2009 05:06:12 -0000	1.40
+++ ocf/cryptosoft.c	25 Feb 2009 04:04:49 -0000
@@ -891,7 +891,7 @@
 	swcr_id = -1;
 }
 
-module_init(cryptosoft_init);
+late_initcall(cryptosoft_init);
 module_exit(cryptosoft_exit);
 
 MODULE_LICENSE("Dual BSD/GPL");

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

[Ocf-linux-users] Make sure HW crypto driver is loaded before cryptosoft

[Hector P. <hec...@di...>]

Hi,

For HW acceleration to work, the kernel crypto driver must be loaded 
*before* the cryptosoft module is loaded.
When building these as loadable modules, it is just a question of 
loading the modules in the correct order:
modprobe <hw-driver>
modprobe cryptosoft
modprobe cryptodev

Now, if I want to have these as built-in features instead of loadable 
modules, how can I guarantee that <hw-driver> is loaded before 
cryptosoft? My driver is a platform device and it is currently being 
probed *after* the kernel has loaded the cryptosoft, so it is not 
working (OCF doesn't know about my driver).

-- 
Héctor Palacios

Re: [Ocf-linux-users] Load balancing in OCF

[Vrabete, B. <bra...@in...>]

---------------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Ocf-linux-users] Load balancing in OCF

[David M. <Dav...@se...>]

Jivin Vrabete, Brad lays it down ...
> Hi Dave,
> 
> According to this white paper (http://www.openbsd.org/papers/ocf.pdf), there
> should be a some load balancing mechanism available. Is your version based
> on FreeBSD or OpenBSD? (Are they different?)

ocf-linux is based on the FreeBSD version,  which is based on the
OpenBSD version.  A link off the ocf-linux home page points to a paper
on the changes in the FreeBSD version,  which seemed reasonable,  and
prompted using that version.

	http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/leffler_crypto/leffler_crypto.pdf

Just checked the code and yes,  it does do session based load balancing.

Just search for cc_sessions in crypto.c,  easy to see it looking for
the best driver to use,  and using cc_sessions (number of sessions per
driver) to find a better match.

Cheers,
Davidm

> >-----Original Message-----
> >From: David McCullough [mailto:Dav...@se...] 
> >Sent: 19 February 2009 04:33
> >To: Vrabete, Brad
> >Cc: ocf...@li...
> >Subject: Re: Load balancing in OCF
> >
> >
> >Jivin Vrabete, Brad lays it down ...
> >> Hi Dave,
> >>
> >> Is load balancing supported in the Linux version of OCF? The FreeBSD 
> >> documentation states that it is supported there.
> >
> >For how long ?
> >
> >I checked just recently,  the FreeBSD code looked like it 
> >hadn't changed from the last OCF release.
> >
> >There is a form of "too busy try the next device" thing.  Not 
> >exactly load balancing IMO.
> >
> >Do you have a pointer to the doc ?  If it looks different I 
> >will double check te hOCF code base is up to date,
> >
> >Cheers,
> >Davidm
> >
> >--
> >David McCullough,  dav...@se...,  
> >Ph:+61 734352815
> >McAfee - SnapGear  http://www.snapgear.com                
> >http://www.uCdot.org
> >



> ---------------------------------------------------------------------
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.


-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org