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