Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Ola Liljedahl]

On 12 October 2015 at 12:33, Agrawal Hemant <hem...@freescale.com> wrote:

> HI Ola,
>
> I guess you are looking for standard NIC style IPSEC task
> offload?
>
Yes. Even if a SoC-based crypto/IPsec/security engine might be able to do a
lot of things, we want the API to be possible to map to off-chip NIC's with
IPsec offload. However I am not very familiar with such NIC's.


>
>
> If yes, should not it be done differently to cover various offload types
> w.r.t PKTIO.
>
That's a good suggestion. But they are not all 100% equivalent, e.g. GSO
doesn't require any configuration or state while IPsec does.


>
> 1.   PKTIO defines the type of offloads available e.g GSO, GRO, TCP,
> IPSEC etc
>
OK


> 2.   The IPSEC decrypted packets can be on any/specific of the
> PKTIO/classification queue.
>
OK


> 3.   In case of IPSEC Session information APIs will only be required.
>
> a.   SA information is typically stored in NIC
>
> b.  RX – packet will be received as plain text(NIC will do the packet
> decryption).
>
Is the SA used for decryption also passed with the decrypted/decapsulated
packet?
I assume that inline IPsec offload should remove the outer IP/ESP/AH
headers.

> c.   TX – packet session information will be passed along with packet
> during enqueue.
>
Or should the SPD lookup be in the NIC/accelerator? Well then you need a
way to configure that. Perhaps it is better to keep this in SW, it's needed
for RX anyway (to check that the received and potentially decrypted packet
was encrypted/decrypted as expected).

How do we pass the SA handle together with the packet on RX and TX? Is this
a magic piece of metadata with ODP get/set accessors?

Thanks,
  Ola

>
>
>
>
> Regards,
>
> Hemant
>
>
>
> *From:* lng-odp [mailto:lng-odp-boun...@lists.linaro.org] *On Behalf Of *Ola
> Liljedahl
> *Sent:* Friday, October 09, 2015 4:53 PM
> *To:* Alexandru Badicioiu <alexandru.badici...@linaro.org>
> *Cc:* LNG ODP Mailman List <lng-odp@lists.linaro.org>
> *Subject:* Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec
> extension
>
>
>
> On 9 October 2015 at 12:48, Alexandru Badicioiu <
> alexandru.badici...@linaro.org> wrote:
>
> So you would like inline/synchronous API mode to have a completion queue
> too? What would be the use for it?
>
> I think we are misunderstanding each other and I haven't been very
> detailed.
>
>
>
> The output of IPsec egress processing must be a queue (e.g. pktio queue)
> where complete packets (L2/L3 encapsulation specified by the user) are
> enqueued. But there probably also needs to be a queue for sending
> notifications of errors or other exceptional events (e.g. SA not found,
> seqno nears the end etc).
>
>
>
> I haven't tried to understand exactly what is needed for inline IPsec on
> ingress.
>
>
>
>
>
> On 9 October 2015 at 13:01, Ola Liljedahl <ola.liljed...@linaro.org>
> wrote:
>
> On 9 October 2015 at 10:37, Alexandru Badicioiu <
> alexandru.badici...@linaro.org> wrote:
>
> This was a long discussion some time ago and the result was that crypto
> output should be abstracted in the form of the completion event and access
> functions would retrieve status and output packets. Also the implementation
> is in charge with crypto completion event allocation and not the
> application even if this is not really supported in HW.
>
> Yes that is useful for lookaside crypto/IPsec operations and my intention
> is not to change that. But this model is not useful for inline IPsec
> acceleration. We need a new or (preferably?) extended API for that. That's
> what I am asking about.
>
>
>
> I know not all silicon vendors would be able to support inline IPsec
> acceleration in HW. But with an Event Machine-like programming model where
> the application uses per-queue call-backs, inline IPsec acceleration can be
> implemented/emulated in SW. Even if this model is not exposed to the user,
> an ODP implementation should be able to do something like it "under the
> hood".
>
>
>
>
>
> The previous approach was that application supplied the completion event
> as being the output packet but this was regarded as a hack.
>
>
>
> Alex
>
>
>
> On 9 October 2015 at 11:28, Ola Liljedahl <ola.liljed...@linaro.org>
> wrote:
>
> On 9 October 2015 at 09:34, Alexandru Badicioiu <
> alexandru.badici...@linaro.org> wrote:
>
> The problem you raised is not strictly related to this patch.
>
> A crypto session has an output queue (for async mode) where the results ,
> including the operation status, will be delivered. There is nothing in the
> API to pr

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Agrawal Hemant]

HI Ola,
I guess you are looking for standard NIC style IPSEC task 
offload?

If yes, should not it be done differently to cover various offload types w.r.t 
PKTIO.


1.   PKTIO defines the type of offloads available e.g GSO, GRO, TCP, IPSEC 
etc

2.   The IPSEC decrypted packets can be on any/specific of the 
PKTIO/classification queue.

3.   In case of IPSEC Session information APIs will only be required.

a.   SA information is typically stored in NIC

b.  RX – packet will be received as plain text(NIC will do the packet 
decryption).

c.   TX – packet session information will be passed along with packet 
during enqueue.



Regards,
Hemant

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Ola 
Liljedahl
Sent: Friday, October 09, 2015 4:53 PM
To: Alexandru Badicioiu <alexandru.badici...@linaro.org>
Cc: LNG ODP Mailman List <lng-odp@lists.linaro.org>
Subject: Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

On 9 October 2015 at 12:48, Alexandru Badicioiu 
<alexandru.badici...@linaro.org<mailto:alexandru.badici...@linaro.org>> wrote:
So you would like inline/synchronous API mode to have a completion queue too? 
What would be the use for it?
I think we are misunderstanding each other and I haven't been very detailed.

The output of IPsec egress processing must be a queue (e.g. pktio queue) where 
complete packets (L2/L3 encapsulation specified by the user) are enqueued. But 
there probably also needs to be a queue for sending notifications of errors or 
other exceptional events (e.g. SA not found, seqno nears the end etc).

I haven't tried to understand exactly what is needed for inline IPsec on 
ingress.


On 9 October 2015 at 13:01, Ola Liljedahl 
<ola.liljed...@linaro.org<mailto:ola.liljed...@linaro.org>> wrote:
On 9 October 2015 at 10:37, Alexandru Badicioiu 
<alexandru.badici...@linaro.org<mailto:alexandru.badici...@linaro.org>> wrote:
This was a long discussion some time ago and the result was that crypto output 
should be abstracted in the form of the completion event and access functions 
would retrieve status and output packets. Also the implementation is in charge 
with crypto completion event allocation and not the application even if this is 
not really supported in HW.
Yes that is useful for lookaside crypto/IPsec operations and my intention is 
not to change that. But this model is not useful for inline IPsec acceleration. 
We need a new or (preferably?) extended API for that. That's what I am asking 
about.

I know not all silicon vendors would be able to support inline IPsec 
acceleration in HW. But with an Event Machine-like programming model where the 
application uses per-queue call-backs, inline IPsec acceleration can be 
implemented/emulated in SW. Even if this model is not exposed to the user, an 
ODP implementation should be able to do something like it "under the hood".


The previous approach was that application supplied the completion event as 
being the output packet but this was regarded as a hack.

Alex

On 9 October 2015 at 11:28, Ola Liljedahl 
<ola.liljed...@linaro.org<mailto:ola.liljed...@linaro.org>> wrote:
On 9 October 2015 at 09:34, Alexandru Badicioiu 
<alexandru.badici...@linaro.org<mailto:alexandru.badici...@linaro.org>> wrote:
The problem you raised is not strictly related to this patch.
A crypto session has an output queue (for async mode) where the results , 
including the operation status, will be delivered. There is nothing in the API 
to prevent using a pktio output queue for crypto completion events but the 
pktio should be able to process the event as the application would do.
In this case an extension of pktio functionality would be required.
Yes but I was thinking of some change (in API and implementation) where the 
output of the crypto operations is the actual packet (with L2/L3 
encapsulation), not a crypto completion event.


Alex


On 8 October 2015 at 20:13, Ola Liljedahl 
<ola.liljed...@linaro.org<mailto:ola.liljed...@linaro.org>> wrote:
Can this proposal be extended to handle inline IPsec processing, e.g. encrypt 
and encapsulate packet (include Ethernet framing) and then send to (enqueue) to 
some user-defined queue (which might be a pktio output queue)?
Need some way to report errors and other conditions back to SW so might need 
some kind of ipsec notification event.
Something for the ingress side as well, e.g. connect user-defined queues to 
IPsec input queue(s) and then specify corresponding output queues.


On 31 July 2015 at 11:30, Alexandru Badicioiu 
<alexandru.badici...@linaro.org<mailto:alexandru.badici...@linaro.org>> wrote:


On 30 July 2015 at 17:44, Stuart Haslam 
<stuart.has...@linaro.org<mailto:stuart.has...@linaro.org>> wrote:
On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
> On 30 July 2015 at 13:50, Stuart Ha

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Ola Liljedahl]

On 9 October 2015 at 09:34, Alexandru Badicioiu <
alexandru.badici...@linaro.org> wrote:

> The problem you raised is not strictly related to this patch.
> A crypto session has an output queue (for async mode) where the results ,
> including the operation status, will be delivered. There is nothing in the
> API to prevent using a pktio output queue for crypto completion events but
> the pktio should be able to process the event as the application would do.
> In this case an extension of pktio functionality would be required.
>
Yes but I was thinking of some change (in API and implementation) where the
output of the crypto operations is the actual packet (with L2/L3
encapsulation), not a crypto completion event.


>
> Alex
>
>
> On 8 October 2015 at 20:13, Ola Liljedahl 
> wrote:
>
>> Can this proposal be extended to handle inline IPsec processing, e.g.
>> encrypt and encapsulate packet (include Ethernet framing) and then send to
>> (enqueue) to some user-defined queue (which might be a pktio output queue)?
>> Need some way to report errors and other conditions back to SW so might
>> need some kind of ipsec notification event.
>> Something for the ingress side as well, e.g. connect user-defined queues
>> to IPsec input queue(s) and then specify corresponding output queues.
>>
>>
>> On 31 July 2015 at 11:30, Alexandru Badicioiu <
>> alexandru.badici...@linaro.org> wrote:
>>
>>>
>>>
>>> On 30 July 2015 at 17:44, Stuart Haslam 
>>> wrote:
>>>
 On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
 > On 30 July 2015 at 13:50, Stuart Haslam 
 wrote:
 >
 > > On Wed, Jul 22, 2015 at 11:26:03AM +0300,
 alexandru.badici...@linaro.org
 > > wrote:
 > > > From: Alexandru Badicioiu 
 > > >
 > > > This patch adds IPSec protocol processing capabilities to crypto
 > > > sesssions. Implementations which have these capabilities in
 hardware
 > > > crypto engines can use the extension to offload the application
 from
 > > > IPSec protocol processing.
 > > >
 > > > Signed-off-by: Alexandru Badicioiu <
 alexandru.badici...@linaro.org>
 > > > ---
 > > >  include/odp/api/crypto_ipsec.h |  110
 > > 
 > > >  platform/linux-generic/include/odp/crypto.h|2 +
 > > >  .../include/odp/plat/crypto_ipsec_types.h  |   53
 ++
 > > >  3 files changed, 165 insertions(+), 0 deletions(-)
 > > >  create mode 100644 include/odp/api/crypto_ipsec.h
 > > >  create mode 100644
 > > platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
 > > >
 > > > diff --git a/include/odp/api/crypto_ipsec.h
 > > b/include/odp/api/crypto_ipsec.h
 > > > new file mode 100644
 > > > index 000..e59fea4
 > > > --- /dev/null
 > > > +++ b/include/odp/api/crypto_ipsec.h
 > > > @@ -0,0 +1,110 @@
 > > > +/* Copyright (c) 2014, Linaro Limited
 > > > + * All rights reserved.
 > > > + *
 > > > + * SPDX-License-Identifier:  BSD-3-Clause
 > > > + */
 > > > +
 > > > +/**
 > > > + * @file
 > > > + *
 > > > + * ODP crypto IPSec extension
 > > > + */
 > > > +
 > > > +#ifndef ODP_API_CRYPTO_IPSEC_H_
 > > > +#define ODP_API_CRYPTO_IPSEC_H_
 > > > +
 > > > +#ifdef __cplusplus
 > > > +extern "C" {
 > > > +#endif
 > > > +
 > > > +/**
 > > > + * @enum odp_ipsec_outhdr_type
 > > > + * IPSec tunnel outer header type
 > > > + *
 > > > + * @enum odp_ipsec_ar_ws
 > > > + * IPSec Anti-replay window size
 > > > + *
 > > > + */
 > > > +
 > > > +typedef struct odp_ipsec_params {
 > > > + uint32_t spi;/** SPI value */
 > > > + uint32_t seq;/** Initial SEQ number */
 > > > + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
 > > > + inbound session with
 > > authentication */
 > >
 > > This name is pretty cryptic, how about just replay_window?
 > >
 > [Alex] The standard name for this parameter is anti-replay window. In
 the
 > context of IPSec this should not be cryptic (odp_ipsec_arw vs
 odp_arw). If
 > your suggestion is to replace the name of the struct member - ar_ws
 with
 > replay_window I'm fine with it but not the name of the enum
 > (odp_ipsec_ar_ws).
 > Or maybe change it to enum odp_ipsec_arw.

 I meant the variable name, don't mind about the enum name.
 [Alex] I'm OK with the change.

 > >
 > > > + odp_bool_t esn; /** Use extended sequence numbers */
 > > > + odp_bool_t auto_iv; /** Auto IV generation for each
 operation.
 > > */
 > > > + uint16_t out_hdr_size;   /** outer header size - tunnel
 mode */
 > > > + 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Alexandru Badicioiu]

This was a long discussion some time ago and the result was that crypto
output should be abstracted in the form of the completion event and access
functions would retrieve status and output packets. Also the implementation
is in charge with crypto completion event allocation and not the
application even if this is not really supported in HW.
The previous approach was that application supplied the completion event as
being the output packet but this was regarded as a hack.

Alex

On 9 October 2015 at 11:28, Ola Liljedahl  wrote:

> On 9 October 2015 at 09:34, Alexandru Badicioiu <
> alexandru.badici...@linaro.org> wrote:
>
>> The problem you raised is not strictly related to this patch.
>> A crypto session has an output queue (for async mode) where the results ,
>> including the operation status, will be delivered. There is nothing in the
>> API to prevent using a pktio output queue for crypto completion events but
>> the pktio should be able to process the event as the application would do.
>> In this case an extension of pktio functionality would be required.
>>
> Yes but I was thinking of some change (in API and implementation) where
> the output of the crypto operations is the actual packet (with L2/L3
> encapsulation), not a crypto completion event.
>
>
>>
>> Alex
>>
>>
>> On 8 October 2015 at 20:13, Ola Liljedahl 
>> wrote:
>>
>>> Can this proposal be extended to handle inline IPsec processing, e.g.
>>> encrypt and encapsulate packet (include Ethernet framing) and then send to
>>> (enqueue) to some user-defined queue (which might be a pktio output queue)?
>>> Need some way to report errors and other conditions back to SW so might
>>> need some kind of ipsec notification event.
>>> Something for the ingress side as well, e.g. connect user-defined queues
>>> to IPsec input queue(s) and then specify corresponding output queues.
>>>
>>>
>>> On 31 July 2015 at 11:30, Alexandru Badicioiu <
>>> alexandru.badici...@linaro.org> wrote:
>>>


 On 30 July 2015 at 17:44, Stuart Haslam 
 wrote:

> On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
> > On 30 July 2015 at 13:50, Stuart Haslam 
> wrote:
> >
> > > On Wed, Jul 22, 2015 at 11:26:03AM +0300,
> alexandru.badici...@linaro.org
> > > wrote:
> > > > From: Alexandru Badicioiu 
> > > >
> > > > This patch adds IPSec protocol processing capabilities to crypto
> > > > sesssions. Implementations which have these capabilities in
> hardware
> > > > crypto engines can use the extension to offload the application
> from
> > > > IPSec protocol processing.
> > > >
> > > > Signed-off-by: Alexandru Badicioiu <
> alexandru.badici...@linaro.org>
> > > > ---
> > > >  include/odp/api/crypto_ipsec.h |  110
> > > 
> > > >  platform/linux-generic/include/odp/crypto.h|2 +
> > > >  .../include/odp/plat/crypto_ipsec_types.h  |   53
> ++
> > > >  3 files changed, 165 insertions(+), 0 deletions(-)
> > > >  create mode 100644 include/odp/api/crypto_ipsec.h
> > > >  create mode 100644
> > > platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
> > > >
> > > > diff --git a/include/odp/api/crypto_ipsec.h
> > > b/include/odp/api/crypto_ipsec.h
> > > > new file mode 100644
> > > > index 000..e59fea4
> > > > --- /dev/null
> > > > +++ b/include/odp/api/crypto_ipsec.h
> > > > @@ -0,0 +1,110 @@
> > > > +/* Copyright (c) 2014, Linaro Limited
> > > > + * All rights reserved.
> > > > + *
> > > > + * SPDX-License-Identifier:  BSD-3-Clause
> > > > + */
> > > > +
> > > > +/**
> > > > + * @file
> > > > + *
> > > > + * ODP crypto IPSec extension
> > > > + */
> > > > +
> > > > +#ifndef ODP_API_CRYPTO_IPSEC_H_
> > > > +#define ODP_API_CRYPTO_IPSEC_H_
> > > > +
> > > > +#ifdef __cplusplus
> > > > +extern "C" {
> > > > +#endif
> > > > +
> > > > +/**
> > > > + * @enum odp_ipsec_outhdr_type
> > > > + * IPSec tunnel outer header type
> > > > + *
> > > > + * @enum odp_ipsec_ar_ws
> > > > + * IPSec Anti-replay window size
> > > > + *
> > > > + */
> > > > +
> > > > +typedef struct odp_ipsec_params {
> > > > + uint32_t spi;/** SPI value */
> > > > + uint32_t seq;/** Initial SEQ number */
> > > > + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
> > > > + inbound session with
> > > authentication */
> > >
> > > This name is pretty cryptic, how about just replay_window?
> > >
> > [Alex] The standard name for this parameter is anti-replay window.
> In the
> > context of IPSec this should 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Ola Liljedahl]

On 9 October 2015 at 10:37, Alexandru Badicioiu <
alexandru.badici...@linaro.org> wrote:

> This was a long discussion some time ago and the result was that crypto
> output should be abstracted in the form of the completion event and access
> functions would retrieve status and output packets. Also the implementation
> is in charge with crypto completion event allocation and not the
> application even if this is not really supported in HW.
>
Yes that is useful for lookaside crypto/IPsec operations and my intention
is not to change that. But this model is not useful for inline IPsec
acceleration. We need a new or (preferably?) extended API for that. That's
what I am asking about.

I know not all silicon vendors would be able to support inline IPsec
acceleration in HW. But with an Event Machine-like programming model where
the application uses per-queue call-backs, inline IPsec acceleration can be
implemented/emulated in SW. Even if this model is not exposed to the user,
an ODP implementation should be able to do something like it "under the
hood".


The previous approach was that application supplied the completion event as
> being the output packet but this was regarded as a hack.
>
> Alex
>
> On 9 October 2015 at 11:28, Ola Liljedahl 
> wrote:
>
>> On 9 October 2015 at 09:34, Alexandru Badicioiu <
>> alexandru.badici...@linaro.org> wrote:
>>
>>> The problem you raised is not strictly related to this patch.
>>> A crypto session has an output queue (for async mode) where the results
>>> , including the operation status, will be delivered. There is nothing in
>>> the API to prevent using a pktio output queue for crypto completion events
>>> but the pktio should be able to process the event as the application would
>>> do.
>>> In this case an extension of pktio functionality would be required.
>>>
>> Yes but I was thinking of some change (in API and implementation) where
>> the output of the crypto operations is the actual packet (with L2/L3
>> encapsulation), not a crypto completion event.
>>
>>
>>>
>>> Alex
>>>
>>>
>>> On 8 October 2015 at 20:13, Ola Liljedahl 
>>> wrote:
>>>
 Can this proposal be extended to handle inline IPsec processing, e.g.
 encrypt and encapsulate packet (include Ethernet framing) and then send to
 (enqueue) to some user-defined queue (which might be a pktio output queue)?
 Need some way to report errors and other conditions back to SW so might
 need some kind of ipsec notification event.
 Something for the ingress side as well, e.g. connect user-defined
 queues to IPsec input queue(s) and then specify corresponding output 
 queues.


 On 31 July 2015 at 11:30, Alexandru Badicioiu <
 alexandru.badici...@linaro.org> wrote:

>
>
> On 30 July 2015 at 17:44, Stuart Haslam 
> wrote:
>
>> On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
>> > On 30 July 2015 at 13:50, Stuart Haslam 
>> wrote:
>> >
>> > > On Wed, Jul 22, 2015 at 11:26:03AM +0300,
>> alexandru.badici...@linaro.org
>> > > wrote:
>> > > > From: Alexandru Badicioiu 
>> > > >
>> > > > This patch adds IPSec protocol processing capabilities to crypto
>> > > > sesssions. Implementations which have these capabilities in
>> hardware
>> > > > crypto engines can use the extension to offload the application
>> from
>> > > > IPSec protocol processing.
>> > > >
>> > > > Signed-off-by: Alexandru Badicioiu <
>> alexandru.badici...@linaro.org>
>> > > > ---
>> > > >  include/odp/api/crypto_ipsec.h |  110
>> > > 
>> > > >  platform/linux-generic/include/odp/crypto.h|2 +
>> > > >  .../include/odp/plat/crypto_ipsec_types.h  |   53
>> ++
>> > > >  3 files changed, 165 insertions(+), 0 deletions(-)
>> > > >  create mode 100644 include/odp/api/crypto_ipsec.h
>> > > >  create mode 100644
>> > > platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
>> > > >
>> > > > diff --git a/include/odp/api/crypto_ipsec.h
>> > > b/include/odp/api/crypto_ipsec.h
>> > > > new file mode 100644
>> > > > index 000..e59fea4
>> > > > --- /dev/null
>> > > > +++ b/include/odp/api/crypto_ipsec.h
>> > > > @@ -0,0 +1,110 @@
>> > > > +/* Copyright (c) 2014, Linaro Limited
>> > > > + * All rights reserved.
>> > > > + *
>> > > > + * SPDX-License-Identifier:  BSD-3-Clause
>> > > > + */
>> > > > +
>> > > > +/**
>> > > > + * @file
>> > > > + *
>> > > > + * ODP crypto IPSec extension
>> > > > + */
>> > > > +
>> > > > +#ifndef ODP_API_CRYPTO_IPSEC_H_
>> > > > +#define ODP_API_CRYPTO_IPSEC_H_
>> > > > +
>> > > > +#ifdef __cplusplus
>> > > > +extern "C" {
>> > > > +#endif

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Alexandru Badicioiu]

The problem you raised is not strictly related to this patch.
A crypto session has an output queue (for async mode) where the results ,
including the operation status, will be delivered. There is nothing in the
API to prevent using a pktio output queue for crypto completion events but
the pktio should be able to process the event as the application would do.
In this case an extension of pktio functionality would be required.

Alex


On 8 October 2015 at 20:13, Ola Liljedahl  wrote:

> Can this proposal be extended to handle inline IPsec processing, e.g.
> encrypt and encapsulate packet (include Ethernet framing) and then send to
> (enqueue) to some user-defined queue (which might be a pktio output queue)?
> Need some way to report errors and other conditions back to SW so might
> need some kind of ipsec notification event.
> Something for the ingress side as well, e.g. connect user-defined queues
> to IPsec input queue(s) and then specify corresponding output queues.
>
>
> On 31 July 2015 at 11:30, Alexandru Badicioiu <
> alexandru.badici...@linaro.org> wrote:
>
>>
>>
>> On 30 July 2015 at 17:44, Stuart Haslam  wrote:
>>
>>> On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
>>> > On 30 July 2015 at 13:50, Stuart Haslam 
>>> wrote:
>>> >
>>> > > On Wed, Jul 22, 2015 at 11:26:03AM +0300,
>>> alexandru.badici...@linaro.org
>>> > > wrote:
>>> > > > From: Alexandru Badicioiu 
>>> > > >
>>> > > > This patch adds IPSec protocol processing capabilities to crypto
>>> > > > sesssions. Implementations which have these capabilities in
>>> hardware
>>> > > > crypto engines can use the extension to offload the application
>>> from
>>> > > > IPSec protocol processing.
>>> > > >
>>> > > > Signed-off-by: Alexandru Badicioiu >> >
>>> > > > ---
>>> > > >  include/odp/api/crypto_ipsec.h |  110
>>> > > 
>>> > > >  platform/linux-generic/include/odp/crypto.h|2 +
>>> > > >  .../include/odp/plat/crypto_ipsec_types.h  |   53
>>> ++
>>> > > >  3 files changed, 165 insertions(+), 0 deletions(-)
>>> > > >  create mode 100644 include/odp/api/crypto_ipsec.h
>>> > > >  create mode 100644
>>> > > platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
>>> > > >
>>> > > > diff --git a/include/odp/api/crypto_ipsec.h
>>> > > b/include/odp/api/crypto_ipsec.h
>>> > > > new file mode 100644
>>> > > > index 000..e59fea4
>>> > > > --- /dev/null
>>> > > > +++ b/include/odp/api/crypto_ipsec.h
>>> > > > @@ -0,0 +1,110 @@
>>> > > > +/* Copyright (c) 2014, Linaro Limited
>>> > > > + * All rights reserved.
>>> > > > + *
>>> > > > + * SPDX-License-Identifier:  BSD-3-Clause
>>> > > > + */
>>> > > > +
>>> > > > +/**
>>> > > > + * @file
>>> > > > + *
>>> > > > + * ODP crypto IPSec extension
>>> > > > + */
>>> > > > +
>>> > > > +#ifndef ODP_API_CRYPTO_IPSEC_H_
>>> > > > +#define ODP_API_CRYPTO_IPSEC_H_
>>> > > > +
>>> > > > +#ifdef __cplusplus
>>> > > > +extern "C" {
>>> > > > +#endif
>>> > > > +
>>> > > > +/**
>>> > > > + * @enum odp_ipsec_outhdr_type
>>> > > > + * IPSec tunnel outer header type
>>> > > > + *
>>> > > > + * @enum odp_ipsec_ar_ws
>>> > > > + * IPSec Anti-replay window size
>>> > > > + *
>>> > > > + */
>>> > > > +
>>> > > > +typedef struct odp_ipsec_params {
>>> > > > + uint32_t spi;/** SPI value */
>>> > > > + uint32_t seq;/** Initial SEQ number */
>>> > > > + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
>>> > > > + inbound session with
>>> > > authentication */
>>> > >
>>> > > This name is pretty cryptic, how about just replay_window?
>>> > >
>>> > [Alex] The standard name for this parameter is anti-replay window. In
>>> the
>>> > context of IPSec this should not be cryptic (odp_ipsec_arw vs
>>> odp_arw). If
>>> > your suggestion is to replace the name of the struct member - ar_ws
>>> with
>>> > replay_window I'm fine with it but not the name of the enum
>>> > (odp_ipsec_ar_ws).
>>> > Or maybe change it to enum odp_ipsec_arw.
>>>
>>> I meant the variable name, don't mind about the enum name.
>>> [Alex] I'm OK with the change.
>>>
>>> > >
>>> > > > + odp_bool_t esn; /** Use extended sequence numbers */
>>> > > > + odp_bool_t auto_iv; /** Auto IV generation for each
>>> operation.
>>> > > */
>>> > > > + uint16_t out_hdr_size;   /** outer header size - tunnel mode
>>> */
>>> > > > + uint8_t *out_hdr;/** outer header - tunnel mode */
>>> > >
>>> > > Can these be 0 and NULL if the application wants tunnel mode but
>>> wants
>>> > > to handle the outer header itself? (i.e. add ESP head/tail and
>>> include
>>> > > inner IP header in encap data)
>>> > >
>>> > [Alex] Yes, that is the intended usage. If requested mode is tunnel and
>>> > there's no out_hdr specified, the application has to add 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Alexandru Badicioiu]

So you would like inline/synchronous API mode to have a completion queue
too? What would be the use for it?

On 9 October 2015 at 13:01, Ola Liljedahl  wrote:

> On 9 October 2015 at 10:37, Alexandru Badicioiu <
> alexandru.badici...@linaro.org> wrote:
>
>> This was a long discussion some time ago and the result was that crypto
>> output should be abstracted in the form of the completion event and access
>> functions would retrieve status and output packets. Also the implementation
>> is in charge with crypto completion event allocation and not the
>> application even if this is not really supported in HW.
>>
> Yes that is useful for lookaside crypto/IPsec operations and my intention
> is not to change that. But this model is not useful for inline IPsec
> acceleration. We need a new or (preferably?) extended API for that. That's
> what I am asking about.
>
> I know not all silicon vendors would be able to support inline IPsec
> acceleration in HW. But with an Event Machine-like programming model where
> the application uses per-queue call-backs, inline IPsec acceleration can be
> implemented/emulated in SW. Even if this model is not exposed to the user,
> an ODP implementation should be able to do something like it "under the
> hood".
>
>
> The previous approach was that application supplied the completion event
>> as being the output packet but this was regarded as a hack.
>>
>> Alex
>>
>> On 9 October 2015 at 11:28, Ola Liljedahl 
>> wrote:
>>
>>> On 9 October 2015 at 09:34, Alexandru Badicioiu <
>>> alexandru.badici...@linaro.org> wrote:
>>>
 The problem you raised is not strictly related to this patch.
 A crypto session has an output queue (for async mode) where the results
 , including the operation status, will be delivered. There is nothing in
 the API to prevent using a pktio output queue for crypto completion events
 but the pktio should be able to process the event as the application would
 do.
 In this case an extension of pktio functionality would be required.

>>> Yes but I was thinking of some change (in API and implementation) where
>>> the output of the crypto operations is the actual packet (with L2/L3
>>> encapsulation), not a crypto completion event.
>>>
>>>

 Alex


 On 8 October 2015 at 20:13, Ola Liljedahl 
 wrote:

> Can this proposal be extended to handle inline IPsec processing, e.g.
> encrypt and encapsulate packet (include Ethernet framing) and then send to
> (enqueue) to some user-defined queue (which might be a pktio output 
> queue)?
> Need some way to report errors and other conditions back to SW so
> might need some kind of ipsec notification event.
> Something for the ingress side as well, e.g. connect user-defined
> queues to IPsec input queue(s) and then specify corresponding output 
> queues.
>
>
> On 31 July 2015 at 11:30, Alexandru Badicioiu <
> alexandru.badici...@linaro.org> wrote:
>
>>
>>
>> On 30 July 2015 at 17:44, Stuart Haslam 
>> wrote:
>>
>>> On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
>>> > On 30 July 2015 at 13:50, Stuart Haslam 
>>> wrote:
>>> >
>>> > > On Wed, Jul 22, 2015 at 11:26:03AM +0300,
>>> alexandru.badici...@linaro.org
>>> > > wrote:
>>> > > > From: Alexandru Badicioiu 
>>> > > >
>>> > > > This patch adds IPSec protocol processing capabilities to
>>> crypto
>>> > > > sesssions. Implementations which have these capabilities in
>>> hardware
>>> > > > crypto engines can use the extension to offload the
>>> application from
>>> > > > IPSec protocol processing.
>>> > > >
>>> > > > Signed-off-by: Alexandru Badicioiu <
>>> alexandru.badici...@linaro.org>
>>> > > > ---
>>> > > >  include/odp/api/crypto_ipsec.h |  110
>>> > > 
>>> > > >  platform/linux-generic/include/odp/crypto.h|2 +
>>> > > >  .../include/odp/plat/crypto_ipsec_types.h  |   53
>>> ++
>>> > > >  3 files changed, 165 insertions(+), 0 deletions(-)
>>> > > >  create mode 100644 include/odp/api/crypto_ipsec.h
>>> > > >  create mode 100644
>>> > > platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
>>> > > >
>>> > > > diff --git a/include/odp/api/crypto_ipsec.h
>>> > > b/include/odp/api/crypto_ipsec.h
>>> > > > new file mode 100644
>>> > > > index 000..e59fea4
>>> > > > --- /dev/null
>>> > > > +++ b/include/odp/api/crypto_ipsec.h
>>> > > > @@ -0,0 +1,110 @@
>>> > > > +/* Copyright (c) 2014, Linaro Limited
>>> > > > + * All rights reserved.
>>> > > > + *
>>> > > > + * SPDX-License-Identifier:  BSD-3-Clause
>>> > > > + */
>>> > > 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Ola Liljedahl]

On 9 October 2015 at 12:48, Alexandru Badicioiu <
alexandru.badici...@linaro.org> wrote:

> So you would like inline/synchronous API mode to have a completion queue
> too? What would be the use for it?
>
I think we are misunderstanding each other and I haven't been very detailed.

The output of IPsec egress processing must be a queue (e.g. pktio queue)
where complete packets (L2/L3 encapsulation specified by the user) are
enqueued. But there probably also needs to be a queue for sending
notifications of errors or other exceptional events (e.g. SA not found,
seqno nears the end etc).

I haven't tried to understand exactly what is needed for inline IPsec on
ingress.


> On 9 October 2015 at 13:01, Ola Liljedahl 
> wrote:
>
>> On 9 October 2015 at 10:37, Alexandru Badicioiu <
>> alexandru.badici...@linaro.org> wrote:
>>
>>> This was a long discussion some time ago and the result was that crypto
>>> output should be abstracted in the form of the completion event and access
>>> functions would retrieve status and output packets. Also the implementation
>>> is in charge with crypto completion event allocation and not the
>>> application even if this is not really supported in HW.
>>>
>> Yes that is useful for lookaside crypto/IPsec operations and my intention
>> is not to change that. But this model is not useful for inline IPsec
>> acceleration. We need a new or (preferably?) extended API for that. That's
>> what I am asking about.
>>
>> I know not all silicon vendors would be able to support inline IPsec
>> acceleration in HW. But with an Event Machine-like programming model where
>> the application uses per-queue call-backs, inline IPsec acceleration can be
>> implemented/emulated in SW. Even if this model is not exposed to the user,
>> an ODP implementation should be able to do something like it "under the
>> hood".
>>
>>
>> The previous approach was that application supplied the completion event
>>> as being the output packet but this was regarded as a hack.
>>>
>>> Alex
>>>
>>> On 9 October 2015 at 11:28, Ola Liljedahl 
>>> wrote:
>>>
 On 9 October 2015 at 09:34, Alexandru Badicioiu <
 alexandru.badici...@linaro.org> wrote:

> The problem you raised is not strictly related to this patch.
> A crypto session has an output queue (for async mode) where the
> results , including the operation status, will be delivered. There is
> nothing in the API to prevent using a pktio output queue for crypto
> completion events but the pktio should be able to process the event as the
> application would do.
> In this case an extension of pktio functionality would be required.
>
 Yes but I was thinking of some change (in API and implementation) where
 the output of the crypto operations is the actual packet (with L2/L3
 encapsulation), not a crypto completion event.


>
> Alex
>
>
> On 8 October 2015 at 20:13, Ola Liljedahl 
> wrote:
>
>> Can this proposal be extended to handle inline IPsec processing, e.g.
>> encrypt and encapsulate packet (include Ethernet framing) and then send 
>> to
>> (enqueue) to some user-defined queue (which might be a pktio output 
>> queue)?
>> Need some way to report errors and other conditions back to SW so
>> might need some kind of ipsec notification event.
>> Something for the ingress side as well, e.g. connect user-defined
>> queues to IPsec input queue(s) and then specify corresponding output 
>> queues.
>>
>>
>> On 31 July 2015 at 11:30, Alexandru Badicioiu <
>> alexandru.badici...@linaro.org> wrote:
>>
>>>
>>>
>>> On 30 July 2015 at 17:44, Stuart Haslam 
>>> wrote:
>>>
 On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
 > On 30 July 2015 at 13:50, Stuart Haslam 
 wrote:
 >
 > > On Wed, Jul 22, 2015 at 11:26:03AM +0300,
 alexandru.badici...@linaro.org
 > > wrote:
 > > > From: Alexandru Badicioiu 
 > > >
 > > > This patch adds IPSec protocol processing capabilities to
 crypto
 > > > sesssions. Implementations which have these capabilities in
 hardware
 > > > crypto engines can use the extension to offload the
 application from
 > > > IPSec protocol processing.
 > > >
 > > > Signed-off-by: Alexandru Badicioiu <
 alexandru.badici...@linaro.org>
 > > > ---
 > > >  include/odp/api/crypto_ipsec.h |  110
 > > 
 > > >  platform/linux-generic/include/odp/crypto.h|2 +
 > > >  .../include/odp/plat/crypto_ipsec_types.h  |   53
 ++
 > > >  3 files changed, 165 insertions(+), 0 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Ola Liljedahl]

Can this proposal be extended to handle inline IPsec processing, e.g.
encrypt and encapsulate packet (include Ethernet framing) and then send to
(enqueue) to some user-defined queue (which might be a pktio output queue)?
Need some way to report errors and other conditions back to SW so might
need some kind of ipsec notification event.
Something for the ingress side as well, e.g. connect user-defined queues to
IPsec input queue(s) and then specify corresponding output queues.


On 31 July 2015 at 11:30, Alexandru Badicioiu <
alexandru.badici...@linaro.org> wrote:

>
>
> On 30 July 2015 at 17:44, Stuart Haslam  wrote:
>
>> On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
>> > On 30 July 2015 at 13:50, Stuart Haslam 
>> wrote:
>> >
>> > > On Wed, Jul 22, 2015 at 11:26:03AM +0300,
>> alexandru.badici...@linaro.org
>> > > wrote:
>> > > > From: Alexandru Badicioiu 
>> > > >
>> > > > This patch adds IPSec protocol processing capabilities to crypto
>> > > > sesssions. Implementations which have these capabilities in hardware
>> > > > crypto engines can use the extension to offload the application from
>> > > > IPSec protocol processing.
>> > > >
>> > > > Signed-off-by: Alexandru Badicioiu 
>> > > > ---
>> > > >  include/odp/api/crypto_ipsec.h |  110
>> > > 
>> > > >  platform/linux-generic/include/odp/crypto.h|2 +
>> > > >  .../include/odp/plat/crypto_ipsec_types.h  |   53
>> ++
>> > > >  3 files changed, 165 insertions(+), 0 deletions(-)
>> > > >  create mode 100644 include/odp/api/crypto_ipsec.h
>> > > >  create mode 100644
>> > > platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
>> > > >
>> > > > diff --git a/include/odp/api/crypto_ipsec.h
>> > > b/include/odp/api/crypto_ipsec.h
>> > > > new file mode 100644
>> > > > index 000..e59fea4
>> > > > --- /dev/null
>> > > > +++ b/include/odp/api/crypto_ipsec.h
>> > > > @@ -0,0 +1,110 @@
>> > > > +/* Copyright (c) 2014, Linaro Limited
>> > > > + * All rights reserved.
>> > > > + *
>> > > > + * SPDX-License-Identifier:  BSD-3-Clause
>> > > > + */
>> > > > +
>> > > > +/**
>> > > > + * @file
>> > > > + *
>> > > > + * ODP crypto IPSec extension
>> > > > + */
>> > > > +
>> > > > +#ifndef ODP_API_CRYPTO_IPSEC_H_
>> > > > +#define ODP_API_CRYPTO_IPSEC_H_
>> > > > +
>> > > > +#ifdef __cplusplus
>> > > > +extern "C" {
>> > > > +#endif
>> > > > +
>> > > > +/**
>> > > > + * @enum odp_ipsec_outhdr_type
>> > > > + * IPSec tunnel outer header type
>> > > > + *
>> > > > + * @enum odp_ipsec_ar_ws
>> > > > + * IPSec Anti-replay window size
>> > > > + *
>> > > > + */
>> > > > +
>> > > > +typedef struct odp_ipsec_params {
>> > > > + uint32_t spi;/** SPI value */
>> > > > + uint32_t seq;/** Initial SEQ number */
>> > > > + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
>> > > > + inbound session with
>> > > authentication */
>> > >
>> > > This name is pretty cryptic, how about just replay_window?
>> > >
>> > [Alex] The standard name for this parameter is anti-replay window. In
>> the
>> > context of IPSec this should not be cryptic (odp_ipsec_arw vs odp_arw).
>> If
>> > your suggestion is to replace the name of the struct member - ar_ws with
>> > replay_window I'm fine with it but not the name of the enum
>> > (odp_ipsec_ar_ws).
>> > Or maybe change it to enum odp_ipsec_arw.
>>
>> I meant the variable name, don't mind about the enum name.
>> [Alex] I'm OK with the change.
>>
>> > >
>> > > > + odp_bool_t esn; /** Use extended sequence numbers */
>> > > > + odp_bool_t auto_iv; /** Auto IV generation for each
>> operation.
>> > > */
>> > > > + uint16_t out_hdr_size;   /** outer header size - tunnel mode
>> */
>> > > > + uint8_t *out_hdr;/** outer header - tunnel mode */
>> > >
>> > > Can these be 0 and NULL if the application wants tunnel mode but wants
>> > > to handle the outer header itself? (i.e. add ESP head/tail and include
>> > > inner IP header in encap data)
>> > >
>> > [Alex] Yes, that is the intended usage. If requested mode is tunnel and
>> > there's no out_hdr specified, the application has to add it.
>>
>>
>>
>> > > > + enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type
>> -
>> > > > + tunnel mode */
>> > > > + odp_bool_t ip_csum; /** update/verify ip header checksum
>> */
>> > > > + odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap
>> &
>> > > decap */
>> > > > + odp_bool_t remove_outer_hdr; /** remove outer header - tunnel
>> mode
>> > > decap */
>> > > > + odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS
>> or
>> > > > + IPv6 Traffic Class byte from the
>> > > inner/outer
>> > > > +

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Alexandru Badicioiu]

On 30 July 2015 at 13:50, Stuart Haslam stuart.has...@linaro.org wrote:

 On Wed, Jul 22, 2015 at 11:26:03AM +0300, alexandru.badici...@linaro.org
 wrote:
  From: Alexandru Badicioiu alexandru.badici...@linaro.org
 
  This patch adds IPSec protocol processing capabilities to crypto
  sesssions. Implementations which have these capabilities in hardware
  crypto engines can use the extension to offload the application from
  IPSec protocol processing.
 
  Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
  ---
   include/odp/api/crypto_ipsec.h |  110
 
   platform/linux-generic/include/odp/crypto.h|2 +
   .../include/odp/plat/crypto_ipsec_types.h  |   53 ++
   3 files changed, 165 insertions(+), 0 deletions(-)
   create mode 100644 include/odp/api/crypto_ipsec.h
   create mode 100644
 platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
 
  diff --git a/include/odp/api/crypto_ipsec.h
 b/include/odp/api/crypto_ipsec.h
  new file mode 100644
  index 000..e59fea4
  --- /dev/null
  +++ b/include/odp/api/crypto_ipsec.h
  @@ -0,0 +1,110 @@
  +/* Copyright (c) 2014, Linaro Limited
  + * All rights reserved.
  + *
  + * SPDX-License-Identifier:  BSD-3-Clause
  + */
  +
  +/**
  + * @file
  + *
  + * ODP crypto IPSec extension
  + */
  +
  +#ifndef ODP_API_CRYPTO_IPSEC_H_
  +#define ODP_API_CRYPTO_IPSEC_H_
  +
  +#ifdef __cplusplus
  +extern C {
  +#endif
  +
  +/**
  + * @enum odp_ipsec_outhdr_type
  + * IPSec tunnel outer header type
  + *
  + * @enum odp_ipsec_ar_ws
  + * IPSec Anti-replay window size
  + *
  + */
  +
  +typedef struct odp_ipsec_params {
  + uint32_t spi;/** SPI value */
  + uint32_t seq;/** Initial SEQ number */
  + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
  + inbound session with
 authentication */

 This name is pretty cryptic, how about just replay_window?

[Alex] The standard name for this parameter is anti-replay window. In the
context of IPSec this should not be cryptic (odp_ipsec_arw vs odp_arw). If
your suggestion is to replace the name of the struct member - ar_ws with
replay_window I'm fine with it but not the name of the enum
(odp_ipsec_ar_ws).
Or maybe change it to enum odp_ipsec_arw.


  + odp_bool_t esn; /** Use extended sequence numbers */
  + odp_bool_t auto_iv; /** Auto IV generation for each operation.
 */
  + uint16_t out_hdr_size;   /** outer header size - tunnel mode */
  + uint8_t *out_hdr;/** outer header - tunnel mode */

 Can these be 0 and NULL if the application wants tunnel mode but wants
 to handle the outer header itself? (i.e. add ESP head/tail and include
 inner IP header in encap data)

[Alex] Yes, that is the intended usage. If requested mode is tunnel and
there's no out_hdr specified, the application has to add it.


  + enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type -
  + tunnel mode */
  + odp_bool_t ip_csum; /** update/verify ip header checksum */
  + odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap 
 decap */
  + odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode
 decap */
  + odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
  + IPv6 Traffic Class byte from the
 inner/outer
  + IP header to the outer/inner IP header
 -
  + tunnel mode encap  decap */
  + odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
  + the inner IP header to the
  + outer IP header - tunnel mode encap */
  + odp_bool_t nat_t;   /** NAT-T encapsulation enabled - tunnel
 mode */
  + odp_bool_t udp_csum;/** Update/verify UDP csum when NAT-T
 enabled */
  +
  +} odp_ipsec_params_t;
  +
  +/**
  + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
  + * IPSec tunnel mode
  + *
  + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
  + * IPSec transport mode
  + *
  + * @enum odp_ipsec_proto
  + * IPSec protocol
  + */
  +
  +/**
  + * Configure crypto session for IPsec processing
  + *
  + * Configures a crypto session for IPSec protocol processing.
  + * Packets submitted to an IPSec enabled session will have
  + * relevant IPSec headers/trailers and tunnel headers
  + * added/removed by the crypto implementation.
  + * For example, the input packet for an IPSec ESP transport
  + * enabled session should be the clear text packet with
  + * no ESP headers/trailers prepared in advance for crypto operation.
  + * The output packet will have ESP header, IV, trailer and the ESP ICV
  + * added by crypto implementation.

 If a packet fails a check on decap (e.g. out of window), presumably the
 application gets an odp_crypto_op_result_t with ok=false, but is there
 any 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Jerin Jacob]

On Wed, Jul 22, 2015 at 11:26:03AM +0300, alexandru.badici...@linaro.org wrote:
 From: Alexandru Badicioiu alexandru.badici...@linaro.org
 
 This patch adds IPSec protocol processing capabilities to crypto
 sesssions. Implementations which have these capabilities in hardware
 crypto engines can use the extension to offload the application from
 IPSec protocol processing.
 
 Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
 ---
  include/odp/api/crypto_ipsec.h |  110 
 
  platform/linux-generic/include/odp/crypto.h|2 +
  .../include/odp/plat/crypto_ipsec_types.h  |   53 ++
  3 files changed, 165 insertions(+), 0 deletions(-)
  create mode 100644 include/odp/api/crypto_ipsec.h
  create mode 100644 
 platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
 
 diff --git a/include/odp/api/crypto_ipsec.h b/include/odp/api/crypto_ipsec.h
 new file mode 100644
 index 000..e59fea4
 --- /dev/null
 +++ b/include/odp/api/crypto_ipsec.h
 @@ -0,0 +1,110 @@
 +/* Copyright (c) 2014, Linaro Limited
 + * All rights reserved.
 + *
 + * SPDX-License-Identifier:  BSD-3-Clause
 + */
 +
 +/**
 + * @file
 + *
 + * ODP crypto IPSec extension
 + */
 +
 +#ifndef ODP_API_CRYPTO_IPSEC_H_
 +#define ODP_API_CRYPTO_IPSEC_H_
 +
 +#ifdef __cplusplus
 +extern C {
 +#endif
 +
 +/**
 + * @enum odp_ipsec_outhdr_type
 + * IPSec tunnel outer header type
 + *
 + * @enum odp_ipsec_ar_ws
 + * IPSec Anti-replay window size
 + *
 + */
 +
 +typedef struct odp_ipsec_params {
 + uint32_t spi;/** SPI value */
 + uint32_t seq;/** Initial SEQ number */
 + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
 + inbound session with authentication */
 + odp_bool_t esn; /** Use extended sequence numbers */
 + odp_bool_t auto_iv; /** Auto IV generation for each operation. */
 + uint16_t out_hdr_size;   /** outer header size - tunnel mode */
 + uint8_t *out_hdr;/** outer header - tunnel mode */
 + enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type -
 + tunnel mode */
 + odp_bool_t ip_csum; /** update/verify ip header checksum */
 + odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap  decap */
 + odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode 
 decap */
 + odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
 + IPv6 Traffic Class byte from the inner/outer
 + IP header to the outer/inner IP header -
 + tunnel mode encap  decap */
 + odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
 + the inner IP header to the
 + outer IP header - tunnel mode encap */
 + odp_bool_t nat_t;   /** NAT-T encapsulation enabled - tunnel mode */
 + odp_bool_t udp_csum;/** Update/verify UDP csum when NAT-T enabled */
 +
 +} odp_ipsec_params_t;
 +
 +/**
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
 + * IPSec tunnel mode
 + *
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
 + * IPSec transport mode
 + *
 + * @enum odp_ipsec_proto
 + * IPSec protocol
 + */
 +
 +/**
 + * Configure crypto session for IPsec processing
 + *
 + * Configures a crypto session for IPSec protocol processing.
 + * Packets submitted to an IPSec enabled session will have
 + * relevant IPSec headers/trailers and tunnel headers
 + * added/removed by the crypto implementation.
 + * For example, the input packet for an IPSec ESP transport
 + * enabled session should be the clear text packet with
 + * no ESP headers/trailers prepared in advance for crypto operation.
 + * The output packet will have ESP header, IV, trailer and the ESP ICV
 + * added by crypto implementation.
 + * Depending on the particular capabilities of an implementation and
 + * the parameters enabled by application, the application may be
 + * partially or completely offloaded from IPSec protocol processing.
 + * For example, if an implementation does not support checksum
 + * update for IP header after adding ESP header the application
 + * should update after crypto IPSec operation.

How a portable application knows what are the pending operations ?


 + *
 + * If an implementation does not support a particular set of
 + * arguments it should return error.
 + *
 + * @param sessionSession handle
 + * @param ipsec_mode IPSec protocol mode
 + * @param ipsec_protoIPSec protocol
 + * @param ipsec_params   IPSec parameters. Parameters which are not
 + *   relevant for selected protocol  mode are ignored -
 + *   e.g. outer_hdr/size set for ESP transport mode.
 + * @retval 0 on success
 + * @retval 0 on failure
 + */
 +int 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Jacob, Jerin]

From: Alexandru Badicioiu alexandru.badici...@linaro.org
Sent: Thursday, July 30, 2015 6:44 PM
To: Jacob, Jerin
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension



On 30 July 2015 at 16:00, Jerin Jacob 
jerin.ja...@caviumnetworks.commailto:jerin.ja...@caviumnetworks.com wrote:
On Wed, Jul 22, 2015 at 11:26:03AM +0300, 
alexandru.badici...@linaro.orgmailto:alexandru.badici...@linaro.org wrote:
 From: Alexandru Badicioiu 
 alexandru.badici...@linaro.orgmailto:alexandru.badici...@linaro.org

 This patch adds IPSec protocol processing capabilities to crypto
 sesssions. Implementations which have these capabilities in hardware
 crypto engines can use the extension to offload the application from
 IPSec protocol processing.

 Signed-off-by: Alexandru Badicioiu 
 alexandru.badici...@linaro.orgmailto:alexandru.badici...@linaro.org
 ---
  include/odp/api/crypto_ipsec.h |  110 
 
  platform/linux-generic/include/odp/crypto.h|2 +
  .../include/odp/plat/crypto_ipsec_types.h  |   53 ++
  3 files changed, 165 insertions(+), 0 deletions(-)
  create mode 100644 include/odp/api/crypto_ipsec.h
  create mode 100644 
 platform/linux-generic/include/odp/plat/crypto_ipsec_types.h

 diff --git a/include/odp/api/crypto_ipsec.h b/include/odp/api/crypto_ipsec.h
 new file mode 100644
 index 000..e59fea4
 --- /dev/null
 +++ b/include/odp/api/crypto_ipsec.h
 @@ -0,0 +1,110 @@
 +/* Copyright (c) 2014, Linaro Limited
 + * All rights reserved.
 + *
 + * SPDX-License-Identifier:  BSD-3-Clause
 + */
 +
 +/**
 + * @file
 + *
 + * ODP crypto IPSec extension
 + */
 +
 +#ifndef ODP_API_CRYPTO_IPSEC_H_
 +#define ODP_API_CRYPTO_IPSEC_H_
 +
 +#ifdef __cplusplus
 +extern C {
 +#endif
 +
 +/**
 + * @enum odp_ipsec_outhdr_type
 + * IPSec tunnel outer header type
 + *
 + * @enum odp_ipsec_ar_ws
 + * IPSec Anti-replay window size
 + *
 + */
 +
 +typedef struct odp_ipsec_params {
 + uint32_t spi;/** SPI value */
 + uint32_t seq;/** Initial SEQ number */
 + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
 + inbound session with authentication */
 + odp_bool_t esn; /** Use extended sequence numbers */
 + odp_bool_t auto_iv; /** Auto IV generation for each operation. */
 + uint16_t out_hdr_size;   /** outer header size - tunnel mode */
 + uint8_t *out_hdr;/** outer header - tunnel mode */
 + enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type -
 + tunnel mode */
 + odp_bool_t ip_csum; /** update/verify ip header checksum */
 + odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap  decap */
 + odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode 
 decap */
 + odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
 + IPv6 Traffic Class byte from the inner/outer
 + IP header to the outer/inner IP header -
 + tunnel mode encap  decap */
 + odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
 + the inner IP header to the
 + outer IP header - tunnel mode encap */
 + odp_bool_t nat_t;   /** NAT-T encapsulation enabled - tunnel mode */
 + odp_bool_t udp_csum;/** Update/verify UDP csum when NAT-T enabled */
 +
 +} odp_ipsec_params_t;
 +
 +/**
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
 + * IPSec tunnel mode
 + *
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
 + * IPSec transport mode
 + *
 + * @enum odp_ipsec_proto
 + * IPSec protocol
 + */
 +
 +/**
 + * Configure crypto session for IPsec processing
 + *
 + * Configures a crypto session for IPSec protocol processing.
 + * Packets submitted to an IPSec enabled session will have
 + * relevant IPSec headers/trailers and tunnel headers
 + * added/removed by the crypto implementation.
 + * For example, the input packet for an IPSec ESP transport
 + * enabled session should be the clear text packet with
 + * no ESP headers/trailers prepared in advance for crypto operation.
 + * The output packet will have ESP header, IV, trailer and the ESP ICV
 + * added by crypto implementation.
 + * Depending on the particular capabilities of an implementation and
 + * the parameters enabled by application, the application may be
 + * partially or completely offloaded from IPSec protocol processing.
 + * For example, if an implementation does not support checksum
 + * update for IP header after adding ESP header the application
 + * should update after crypto IPSec operation.

How a portable application knows what are the pending operations ?
[Alex] I assume your question is related to asynchronous mode. A crypto 
operation can have an associated

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Stuart Haslam]

On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
 On 30 July 2015 at 13:50, Stuart Haslam stuart.has...@linaro.org wrote:
 
  On Wed, Jul 22, 2015 at 11:26:03AM +0300, alexandru.badici...@linaro.org
  wrote:
   From: Alexandru Badicioiu alexandru.badici...@linaro.org
  
   This patch adds IPSec protocol processing capabilities to crypto
   sesssions. Implementations which have these capabilities in hardware
   crypto engines can use the extension to offload the application from
   IPSec protocol processing.
  
   Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
   ---
include/odp/api/crypto_ipsec.h |  110
  
platform/linux-generic/include/odp/crypto.h|2 +
.../include/odp/plat/crypto_ipsec_types.h  |   53 ++
3 files changed, 165 insertions(+), 0 deletions(-)
create mode 100644 include/odp/api/crypto_ipsec.h
create mode 100644
  platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
  
   diff --git a/include/odp/api/crypto_ipsec.h
  b/include/odp/api/crypto_ipsec.h
   new file mode 100644
   index 000..e59fea4
   --- /dev/null
   +++ b/include/odp/api/crypto_ipsec.h
   @@ -0,0 +1,110 @@
   +/* Copyright (c) 2014, Linaro Limited
   + * All rights reserved.
   + *
   + * SPDX-License-Identifier:  BSD-3-Clause
   + */
   +
   +/**
   + * @file
   + *
   + * ODP crypto IPSec extension
   + */
   +
   +#ifndef ODP_API_CRYPTO_IPSEC_H_
   +#define ODP_API_CRYPTO_IPSEC_H_
   +
   +#ifdef __cplusplus
   +extern C {
   +#endif
   +
   +/**
   + * @enum odp_ipsec_outhdr_type
   + * IPSec tunnel outer header type
   + *
   + * @enum odp_ipsec_ar_ws
   + * IPSec Anti-replay window size
   + *
   + */
   +
   +typedef struct odp_ipsec_params {
   + uint32_t spi;/** SPI value */
   + uint32_t seq;/** Initial SEQ number */
   + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
   + inbound session with
  authentication */
 
  This name is pretty cryptic, how about just replay_window?
 
 [Alex] The standard name for this parameter is anti-replay window. In the
 context of IPSec this should not be cryptic (odp_ipsec_arw vs odp_arw). If
 your suggestion is to replace the name of the struct member - ar_ws with
 replay_window I'm fine with it but not the name of the enum
 (odp_ipsec_ar_ws).
 Or maybe change it to enum odp_ipsec_arw.

I meant the variable name, don't mind about the enum name.

 
   + odp_bool_t esn; /** Use extended sequence numbers */
   + odp_bool_t auto_iv; /** Auto IV generation for each operation.
  */
   + uint16_t out_hdr_size;   /** outer header size - tunnel mode */
   + uint8_t *out_hdr;/** outer header - tunnel mode */
 
  Can these be 0 and NULL if the application wants tunnel mode but wants
  to handle the outer header itself? (i.e. add ESP head/tail and include
  inner IP header in encap data)
 
 [Alex] Yes, that is the intended usage. If requested mode is tunnel and
 there's no out_hdr specified, the application has to add it.



   + enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type -
   + tunnel mode */
   + odp_bool_t ip_csum; /** update/verify ip header checksum */
   + odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap 
  decap */
   + odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode
  decap */
   + odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
   + IPv6 Traffic Class byte from the
  inner/outer
   + IP header to the outer/inner IP header
  -
   + tunnel mode encap  decap */
   + odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
   + the inner IP header to the
   + outer IP header - tunnel mode encap */
   + odp_bool_t nat_t;   /** NAT-T encapsulation enabled - tunnel
  mode */
   + odp_bool_t udp_csum;/** Update/verify UDP csum when NAT-T
  enabled */
   +
   +} odp_ipsec_params_t;
   +
   +/**
   + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
   + * IPSec tunnel mode
   + *
   + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
   + * IPSec transport mode
   + *
   + * @enum odp_ipsec_proto
   + * IPSec protocol
   + */
   +
   +/**
   + * Configure crypto session for IPsec processing
   + *
   + * Configures a crypto session for IPSec protocol processing.
   + * Packets submitted to an IPSec enabled session will have
   + * relevant IPSec headers/trailers and tunnel headers
   + * added/removed by the crypto implementation.
   + * For example, the input packet for an IPSec ESP transport
   + * enabled session should be the clear text packet with
   + * no ESP headers/trailers prepared in advance for crypto operation.
   + 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Stuart Haslam]

On Wed, Jul 22, 2015 at 11:26:03AM +0300, alexandru.badici...@linaro.org wrote:
 From: Alexandru Badicioiu alexandru.badici...@linaro.org
 
 This patch adds IPSec protocol processing capabilities to crypto
 sesssions. Implementations which have these capabilities in hardware
 crypto engines can use the extension to offload the application from
 IPSec protocol processing.
 
 Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
 ---
  include/odp/api/crypto_ipsec.h |  110 
 
  platform/linux-generic/include/odp/crypto.h|2 +
  .../include/odp/plat/crypto_ipsec_types.h  |   53 ++
  3 files changed, 165 insertions(+), 0 deletions(-)
  create mode 100644 include/odp/api/crypto_ipsec.h
  create mode 100644 
 platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
 
 diff --git a/include/odp/api/crypto_ipsec.h b/include/odp/api/crypto_ipsec.h
 new file mode 100644
 index 000..e59fea4
 --- /dev/null
 +++ b/include/odp/api/crypto_ipsec.h
 @@ -0,0 +1,110 @@
 +/* Copyright (c) 2014, Linaro Limited
 + * All rights reserved.
 + *
 + * SPDX-License-Identifier:  BSD-3-Clause
 + */
 +
 +/**
 + * @file
 + *
 + * ODP crypto IPSec extension
 + */
 +
 +#ifndef ODP_API_CRYPTO_IPSEC_H_
 +#define ODP_API_CRYPTO_IPSEC_H_
 +
 +#ifdef __cplusplus
 +extern C {
 +#endif
 +
 +/**
 + * @enum odp_ipsec_outhdr_type
 + * IPSec tunnel outer header type
 + *
 + * @enum odp_ipsec_ar_ws
 + * IPSec Anti-replay window size
 + *
 + */
 +
 +typedef struct odp_ipsec_params {
 + uint32_t spi;/** SPI value */
 + uint32_t seq;/** Initial SEQ number */
 + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
 + inbound session with authentication */

This name is pretty cryptic, how about just replay_window?

 + odp_bool_t esn; /** Use extended sequence numbers */
 + odp_bool_t auto_iv; /** Auto IV generation for each operation. */
 + uint16_t out_hdr_size;   /** outer header size - tunnel mode */
 + uint8_t *out_hdr;/** outer header - tunnel mode */

Can these be 0 and NULL if the application wants tunnel mode but wants
to handle the outer header itself? (i.e. add ESP head/tail and include
inner IP header in encap data)

 + enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type -
 + tunnel mode */
 + odp_bool_t ip_csum; /** update/verify ip header checksum */
 + odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap  decap */
 + odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode 
 decap */
 + odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
 + IPv6 Traffic Class byte from the inner/outer
 + IP header to the outer/inner IP header -
 + tunnel mode encap  decap */
 + odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
 + the inner IP header to the
 + outer IP header - tunnel mode encap */
 + odp_bool_t nat_t;   /** NAT-T encapsulation enabled - tunnel mode */
 + odp_bool_t udp_csum;/** Update/verify UDP csum when NAT-T enabled */
 +
 +} odp_ipsec_params_t;
 +
 +/**
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
 + * IPSec tunnel mode
 + *
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
 + * IPSec transport mode
 + *
 + * @enum odp_ipsec_proto
 + * IPSec protocol
 + */
 +
 +/**
 + * Configure crypto session for IPsec processing
 + *
 + * Configures a crypto session for IPSec protocol processing.
 + * Packets submitted to an IPSec enabled session will have
 + * relevant IPSec headers/trailers and tunnel headers
 + * added/removed by the crypto implementation.
 + * For example, the input packet for an IPSec ESP transport
 + * enabled session should be the clear text packet with
 + * no ESP headers/trailers prepared in advance for crypto operation.
 + * The output packet will have ESP header, IV, trailer and the ESP ICV
 + * added by crypto implementation.

If a packet fails a check on decap (e.g. out of window), presumably the
application gets an odp_crypto_op_result_t with ok=false, but is there
any way for it to tell what failed?

 + * Depending on the particular capabilities of an implementation and
 + * the parameters enabled by application, the application may be
 + * partially or completely offloaded from IPSec protocol processing.
 + * For example, if an implementation does not support checksum
 + * update for IP header after adding ESP header the application
 + * should update after crypto IPSec operation.
 + *
 + * If an implementation does not support a particular set of
 + * arguments it should return error.
 + *
 + * @param sessionSession handle
 + * @param ipsec_mode IPSec protocol mode
 + * @param ipsec_protoIPSec 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Maxim Uvarov]

On 07/30/15 12:04, Alexandru Badicioiu wrote:

Ping.


Alex, Mike replayed to you to fix minor fixes.

Maxim.


On 22 July 2015 at 11:26, alexandru.badici...@linaro.org 
mailto:alexandru.badici...@linaro.org wrote:


From: Alexandru Badicioiu alexandru.badici...@linaro.org
mailto:alexandru.badici...@linaro.org

This patch adds IPSec protocol processing capabilities to crypto
sesssions. Implementations which have these capabilities in hardware
crypto engines can use the extension to offload the application from
IPSec protocol processing.

Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
mailto:alexandru.badici...@linaro.org
---
 include/odp/api/crypto_ipsec.h |  110

 platform/linux-generic/include/odp/crypto.h|2 +
 .../include/odp/plat/crypto_ipsec_types.h  |   53 ++
 3 files changed, 165 insertions(+), 0 deletions(-)
 create mode 100644 include/odp/api/crypto_ipsec.h
 create mode 100644
platform/linux-generic/include/odp/plat/crypto_ipsec_types.h

diff --git a/include/odp/api/crypto_ipsec.h
b/include/odp/api/crypto_ipsec.h
new file mode 100644
index 000..e59fea4
--- /dev/null
+++ b/include/odp/api/crypto_ipsec.h
@@ -0,0 +1,110 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP crypto IPSec extension
+ */
+
+#ifndef ODP_API_CRYPTO_IPSEC_H_
+#define ODP_API_CRYPTO_IPSEC_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+/**
+ * @enum odp_ipsec_outhdr_type
+ * IPSec tunnel outer header type
+ *
+ * @enum odp_ipsec_ar_ws
+ * IPSec Anti-replay window size
+ *
+ */
+
+typedef struct odp_ipsec_params {
+   uint32_t spi;/** SPI value */
+   uint32_t seq;/** Initial SEQ number */
+   enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
+   inbound session with
authentication */
+   odp_bool_t esn; /** Use extended sequence numbers */
+   odp_bool_t auto_iv; /** Auto IV generation for each
operation. */
+   uint16_t out_hdr_size;   /** outer header size - tunnel
mode */
+   uint8_t *out_hdr;/** outer header - tunnel mode */
+   enum odp_ipsec_outhdr_type out_hdr_type; /* outer header
type -
+   tunnel mode */
+   odp_bool_t ip_csum; /** update/verify ip header
checksum */
+   odp_bool_t ip_dttl; /** decrement ttl - tunnel mode
encap  decap */
+   odp_bool_t remove_outer_hdr; /** remove outer header -
tunnel mode decap */
+   odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4
TOS or
+   IPv6 Traffic Class byte from
the inner/outer
+   IP header to the outer/inner
IP header -
+   tunnel mode encap  decap */
+   odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
+   the inner IP header to the
+   outer IP header - tunnel mode
encap */
+   odp_bool_t nat_t;   /** NAT-T encapsulation enabled -
tunnel mode */
+   odp_bool_t udp_csum;/** Update/verify UDP csum when
NAT-T enabled */
+
+} odp_ipsec_params_t;
+
+/**
+ * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
+ * IPSec tunnel mode
+ *
+ * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
+ * IPSec transport mode
+ *
+ * @enum odp_ipsec_proto
+ * IPSec protocol
+ */
+
+/**
+ * Configure crypto session for IPsec processing
+ *
+ * Configures a crypto session for IPSec protocol processing.
+ * Packets submitted to an IPSec enabled session will have
+ * relevant IPSec headers/trailers and tunnel headers
+ * added/removed by the crypto implementation.
+ * For example, the input packet for an IPSec ESP transport
+ * enabled session should be the clear text packet with
+ * no ESP headers/trailers prepared in advance for crypto operation.
+ * The output packet will have ESP header, IV, trailer and the
ESP ICV
+ * added by crypto implementation.
+ * Depending on the particular capabilities of an implementation and
+ * the parameters enabled by application, the application may be
+ * partially or completely offloaded from IPSec protocol processing.
+ * For example, if an implementation does not support checksum
+ * update for IP header after adding ESP header the application
+ * should update after crypto IPSec operation.
+ *
+ * If an 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Alexandru Badicioiu]

Hi Maxim, I noticed that but I wanted to know if there are some other
comments more oriented to the functionality this patch proposes.

Thanks,
Alex

On 30 July 2015 at 12:21, Maxim Uvarov maxim.uva...@linaro.org wrote:

 On 07/30/15 12:04, Alexandru Badicioiu wrote:

 Ping.


 Alex, Mike replayed to you to fix minor fixes.

 Maxim.


 On 22 July 2015 at 11:26, alexandru.badici...@linaro.org mailto:
 alexandru.badici...@linaro.org wrote:

 From: Alexandru Badicioiu alexandru.badici...@linaro.org
 mailto:alexandru.badici...@linaro.org

 This patch adds IPSec protocol processing capabilities to crypto
 sesssions. Implementations which have these capabilities in hardware
 crypto engines can use the extension to offload the application from
 IPSec protocol processing.

 Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
 mailto:alexandru.badici...@linaro.org

 ---
  include/odp/api/crypto_ipsec.h |  110
 
  platform/linux-generic/include/odp/crypto.h|2 +
  .../include/odp/plat/crypto_ipsec_types.h  |   53 ++
  3 files changed, 165 insertions(+), 0 deletions(-)
  create mode 100644 include/odp/api/crypto_ipsec.h
  create mode 100644
 platform/linux-generic/include/odp/plat/crypto_ipsec_types.h

 diff --git a/include/odp/api/crypto_ipsec.h
 b/include/odp/api/crypto_ipsec.h
 new file mode 100644
 index 000..e59fea4
 --- /dev/null
 +++ b/include/odp/api/crypto_ipsec.h
 @@ -0,0 +1,110 @@
 +/* Copyright (c) 2014, Linaro Limited
 + * All rights reserved.
 + *
 + * SPDX-License-Identifier:BSD-3-Clause
 + */
 +
 +/**
 + * @file
 + *
 + * ODP crypto IPSec extension
 + */
 +
 +#ifndef ODP_API_CRYPTO_IPSEC_H_
 +#define ODP_API_CRYPTO_IPSEC_H_
 +
 +#ifdef __cplusplus
 +extern C {
 +#endif
 +
 +/**
 + * @enum odp_ipsec_outhdr_type
 + * IPSec tunnel outer header type
 + *
 + * @enum odp_ipsec_ar_ws
 + * IPSec Anti-replay window size
 + *
 + */
 +
 +typedef struct odp_ipsec_params {
 +   uint32_t spi;/** SPI value */
 +   uint32_t seq;/** Initial SEQ number */
 +   enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
 +   inbound session with
 authentication */
 +   odp_bool_t esn; /** Use extended sequence numbers */
 +   odp_bool_t auto_iv; /** Auto IV generation for each
 operation. */
 +   uint16_t out_hdr_size;   /** outer header size - tunnel
 mode */
 +   uint8_t *out_hdr;/** outer header - tunnel mode */
 +   enum odp_ipsec_outhdr_type out_hdr_type; /* outer header
 type -
 +   tunnel mode */
 +   odp_bool_t ip_csum; /** update/verify ip header
 checksum */
 +   odp_bool_t ip_dttl; /** decrement ttl - tunnel mode
 encap  decap */
 +   odp_bool_t remove_outer_hdr; /** remove outer header -
 tunnel mode decap */
 +   odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4
 TOS or
 +   IPv6 Traffic Class byte from
 the inner/outer
 +   IP header to the outer/inner
 IP header -
 +   tunnel mode encap  decap */
 +   odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
 +   the inner IP header to the
 +   outer IP header - tunnel mode
 encap */
 +   odp_bool_t nat_t;   /** NAT-T encapsulation enabled -
 tunnel mode */
 +   odp_bool_t udp_csum;/** Update/verify UDP csum when
 NAT-T enabled */
 +
 +} odp_ipsec_params_t;
 +
 +/**
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
 + * IPSec tunnel mode
 + *
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
 + * IPSec transport mode
 + *
 + * @enum odp_ipsec_proto
 + * IPSec protocol
 + */
 +
 +/**
 + * Configure crypto session for IPsec processing
 + *
 + * Configures a crypto session for IPSec protocol processing.
 + * Packets submitted to an IPSec enabled session will have
 + * relevant IPSec headers/trailers and tunnel headers
 + * added/removed by the crypto implementation.
 + * For example, the input packet for an IPSec ESP transport
 + * enabled session should be the clear text packet with
 + * no ESP headers/trailers prepared in advance for crypto operation.
 + * The output packet will have ESP header, IV, trailer and the
 ESP ICV
 + * added by crypto implementation.
 + * Depending on the particular capabilities of an implementation and
 + * the 

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Alexandru Badicioiu]

Ping.

On 22 July 2015 at 11:26, alexandru.badici...@linaro.org wrote:

 From: Alexandru Badicioiu alexandru.badici...@linaro.org

 This patch adds IPSec protocol processing capabilities to crypto
 sesssions. Implementations which have these capabilities in hardware
 crypto engines can use the extension to offload the application from
 IPSec protocol processing.

 Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
 ---
  include/odp/api/crypto_ipsec.h |  110
 
  platform/linux-generic/include/odp/crypto.h|2 +
  .../include/odp/plat/crypto_ipsec_types.h  |   53 ++
  3 files changed, 165 insertions(+), 0 deletions(-)
  create mode 100644 include/odp/api/crypto_ipsec.h
  create mode 100644
 platform/linux-generic/include/odp/plat/crypto_ipsec_types.h

 diff --git a/include/odp/api/crypto_ipsec.h
 b/include/odp/api/crypto_ipsec.h
 new file mode 100644
 index 000..e59fea4
 --- /dev/null
 +++ b/include/odp/api/crypto_ipsec.h
 @@ -0,0 +1,110 @@
 +/* Copyright (c) 2014, Linaro Limited
 + * All rights reserved.
 + *
 + * SPDX-License-Identifier:BSD-3-Clause
 + */
 +
 +/**
 + * @file
 + *
 + * ODP crypto IPSec extension
 + */
 +
 +#ifndef ODP_API_CRYPTO_IPSEC_H_
 +#define ODP_API_CRYPTO_IPSEC_H_
 +
 +#ifdef __cplusplus
 +extern C {
 +#endif
 +
 +/**
 + * @enum odp_ipsec_outhdr_type
 + * IPSec tunnel outer header type
 + *
 + * @enum odp_ipsec_ar_ws
 + * IPSec Anti-replay window size
 + *
 + */
 +
 +typedef struct odp_ipsec_params {
 +   uint32_t spi;/** SPI value */
 +   uint32_t seq;/** Initial SEQ number */
 +   enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
 +   inbound session with
 authentication */
 +   odp_bool_t esn; /** Use extended sequence numbers */
 +   odp_bool_t auto_iv; /** Auto IV generation for each operation.
 */
 +   uint16_t out_hdr_size;   /** outer header size - tunnel mode */
 +   uint8_t *out_hdr;/** outer header - tunnel mode */
 +   enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type -
 +   tunnel mode */
 +   odp_bool_t ip_csum; /** update/verify ip header checksum */
 +   odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap 
 decap */
 +   odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode
 decap */
 +   odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
 +   IPv6 Traffic Class byte from the
 inner/outer
 +   IP header to the outer/inner IP header
 -
 +   tunnel mode encap  decap */
 +   odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
 +   the inner IP header to the
 +   outer IP header - tunnel mode encap */
 +   odp_bool_t nat_t;   /** NAT-T encapsulation enabled - tunnel
 mode */
 +   odp_bool_t udp_csum;/** Update/verify UDP csum when NAT-T
 enabled */
 +
 +} odp_ipsec_params_t;
 +
 +/**
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
 + * IPSec tunnel mode
 + *
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
 + * IPSec transport mode
 + *
 + * @enum odp_ipsec_proto
 + * IPSec protocol
 + */
 +
 +/**
 + * Configure crypto session for IPsec processing
 + *
 + * Configures a crypto session for IPSec protocol processing.
 + * Packets submitted to an IPSec enabled session will have
 + * relevant IPSec headers/trailers and tunnel headers
 + * added/removed by the crypto implementation.
 + * For example, the input packet for an IPSec ESP transport
 + * enabled session should be the clear text packet with
 + * no ESP headers/trailers prepared in advance for crypto operation.
 + * The output packet will have ESP header, IV, trailer and the ESP ICV
 + * added by crypto implementation.
 + * Depending on the particular capabilities of an implementation and
 + * the parameters enabled by application, the application may be
 + * partially or completely offloaded from IPSec protocol processing.
 + * For example, if an implementation does not support checksum
 + * update for IP header after adding ESP header the application
 + * should update after crypto IPSec operation.
 + *
 + * If an implementation does not support a particular set of
 + * arguments it should return error.
 + *
 + * @param session  Session handle
 + * @param ipsec_mode   IPSec protocol mode
 + * @param ipsec_proto  IPSec protocol
 + * @param ipsec_params IPSec parameters. Parameters which are not
 + * relevant for selected protocol  mode are
 ignored -
 + * e.g. outer_hdr/size set for ESP transport mode.
 + * @retval 0 on success
 + * @retval 0 on failure
 + */
 +int odp_crypto_session_config_ipsec(odp_crypto_session_t session,
 +

[lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[alexandru.badicioiu]

From: Alexandru Badicioiu alexandru.badici...@linaro.org

This patch adds IPSec protocol processing capabilities to crypto
sesssions. Implementations which have these capabilities in hardware
crypto engines can use the extension to offload the application from
IPSec protocol processing.

Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
---
 include/odp/api/crypto_ipsec.h |  110 
 platform/linux-generic/include/odp/crypto.h|2 +
 .../include/odp/plat/crypto_ipsec_types.h  |   53 ++
 3 files changed, 165 insertions(+), 0 deletions(-)
 create mode 100644 include/odp/api/crypto_ipsec.h
 create mode 100644 platform/linux-generic/include/odp/plat/crypto_ipsec_types.h

diff --git a/include/odp/api/crypto_ipsec.h b/include/odp/api/crypto_ipsec.h
new file mode 100644
index 000..e59fea4
--- /dev/null
+++ b/include/odp/api/crypto_ipsec.h
@@ -0,0 +1,110 @@
+/* Copyright (c) 2014, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP crypto IPSec extension
+ */
+
+#ifndef ODP_API_CRYPTO_IPSEC_H_
+#define ODP_API_CRYPTO_IPSEC_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+/**
+ * @enum odp_ipsec_outhdr_type
+ * IPSec tunnel outer header type
+ *
+ * @enum odp_ipsec_ar_ws
+ * IPSec Anti-replay window size
+ *
+ */
+
+typedef struct odp_ipsec_params {
+   uint32_t spi;/** SPI value */
+   uint32_t seq;/** Initial SEQ number */
+   enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
+   inbound session with authentication */
+   odp_bool_t esn; /** Use extended sequence numbers */
+   odp_bool_t auto_iv; /** Auto IV generation for each operation. */
+   uint16_t out_hdr_size;   /** outer header size - tunnel mode */
+   uint8_t *out_hdr;/** outer header - tunnel mode */
+   enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type -
+   tunnel mode */
+   odp_bool_t ip_csum; /** update/verify ip header checksum */
+   odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap  decap */
+   odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode 
decap */
+   odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
+   IPv6 Traffic Class byte from the inner/outer
+   IP header to the outer/inner IP header -
+   tunnel mode encap  decap */
+   odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
+   the inner IP header to the
+   outer IP header - tunnel mode encap */
+   odp_bool_t nat_t;   /** NAT-T encapsulation enabled - tunnel mode */
+   odp_bool_t udp_csum;/** Update/verify UDP csum when NAT-T enabled */
+
+} odp_ipsec_params_t;
+
+/**
+ * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
+ * IPSec tunnel mode
+ *
+ * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
+ * IPSec transport mode
+ *
+ * @enum odp_ipsec_proto
+ * IPSec protocol
+ */
+
+/**
+ * Configure crypto session for IPsec processing
+ *
+ * Configures a crypto session for IPSec protocol processing.
+ * Packets submitted to an IPSec enabled session will have
+ * relevant IPSec headers/trailers and tunnel headers
+ * added/removed by the crypto implementation.
+ * For example, the input packet for an IPSec ESP transport
+ * enabled session should be the clear text packet with
+ * no ESP headers/trailers prepared in advance for crypto operation.
+ * The output packet will have ESP header, IV, trailer and the ESP ICV
+ * added by crypto implementation.
+ * Depending on the particular capabilities of an implementation and
+ * the parameters enabled by application, the application may be
+ * partially or completely offloaded from IPSec protocol processing.
+ * For example, if an implementation does not support checksum
+ * update for IP header after adding ESP header the application
+ * should update after crypto IPSec operation.
+ *
+ * If an implementation does not support a particular set of
+ * arguments it should return error.
+ *
+ * @param session  Session handle
+ * @param ipsec_mode   IPSec protocol mode
+ * @param ipsec_proto  IPSec protocol
+ * @param ipsec_params IPSec parameters. Parameters which are not
+ * relevant for selected protocol  mode are ignored -
+ * e.g. outer_hdr/size set for ESP transport mode.
+ * @retval 0 on success
+ * @retval 0 on failure
+ */
+int odp_crypto_session_config_ipsec(odp_crypto_session_t session,
+   enum odp_ipsec_mode ipsec_mode,
+   enum odp_ipsec_proto ipsec_proto,
+   odp_ipsec_params_t ipsec_params);
+

Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension

[Mike Holmes]

Minor fixes

On 22 July 2015 at 04:26, alexandru.badici...@linaro.org wrote:

 From: Alexandru Badicioiu alexandru.badici...@linaro.org

 This patch adds IPSec protocol processing capabilities to crypto
 sesssions. Implementations which have these capabilities in hardware
 crypto engines can use the extension to offload the application from
 IPSec protocol processing.

 Signed-off-by: Alexandru Badicioiu alexandru.badici...@linaro.org
 ---
  include/odp/api/crypto_ipsec.h |  110
 
  platform/linux-generic/include/odp/crypto.h|2 +
  .../include/odp/plat/crypto_ipsec_types.h  |   53 ++
  3 files changed, 165 insertions(+), 0 deletions(-)
  create mode 100644 include/odp/api/crypto_ipsec.h
  create mode 100644
 platform/linux-generic/include/odp/plat/crypto_ipsec_types.h

 diff --git a/include/odp/api/crypto_ipsec.h
 b/include/odp/api/crypto_ipsec.h
 new file mode 100644
 index 000..e59fea4
 --- /dev/null
 +++ b/include/odp/api/crypto_ipsec.h
 @@ -0,0 +1,110 @@
 +/* Copyright (c) 2014, Linaro Limited


2015


 + * All rights reserved.
 + *
 + * SPDX-License-Identifier:BSD-3-Clause
 + */
 +
 +/**
 + * @file
 + *
 + * ODP crypto IPSec extension
 + */
 +
 +#ifndef ODP_API_CRYPTO_IPSEC_H_
 +#define ODP_API_CRYPTO_IPSEC_H_
 +
 +#ifdef __cplusplus
 +extern C {
 +#endif
 +
 +/**
 + * @enum odp_ipsec_outhdr_type
 + * IPSec tunnel outer header type
 + *
 + * @enum odp_ipsec_ar_ws
 + * IPSec Anti-replay window size
 + *
 + */
 +
 +typedef struct odp_ipsec_params {
 +   uint32_t spi;/** SPI value */
 +   uint32_t seq;/** Initial SEQ number */
 +   enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
 +   inbound session with
 authentication */
 +   odp_bool_t esn; /** Use extended sequence numbers */
 +   odp_bool_t auto_iv; /** Auto IV generation for each operation.
 */
 +   uint16_t out_hdr_size;   /** outer header size - tunnel mode */
 +   uint8_t *out_hdr;/** outer header - tunnel mode */
 +   enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type -
 +   tunnel mode */
 +   odp_bool_t ip_csum; /** update/verify ip header checksum */
 +   odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap 
 decap */
 +   odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode
 decap */
 +   odp_bool_t copy_dscp;   /** DiffServ Copy - Copy the IPv4 TOS or
 +   IPv6 Traffic Class byte from the
 inner/outer
 +   IP header to the outer/inner IP header
 -
 +   tunnel mode encap  decap */
 +   odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
 +   the inner IP header to the
 +   outer IP header - tunnel mode encap */
 +   odp_bool_t nat_t;   /** NAT-T encapsulation enabled - tunnel
 mode */
 +   odp_bool_t udp_csum;/** Update/verify UDP csum when NAT-T
 enabled */
 +
 +} odp_ipsec_params_t;
 +
 +/**
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
 + * IPSec tunnel mode
 + *
 + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
 + * IPSec transport mode
 + *
 + * @enum odp_ipsec_proto
 + * IPSec protocol
 + */
 +
 +/**
 + * Configure crypto session for IPsec processing
 + *
 + * Configures a crypto session for IPSec protocol processing.
 + * Packets submitted to an IPSec enabled session will have
 + * relevant IPSec headers/trailers and tunnel headers
 + * added/removed by the crypto implementation.
 + * For example, the input packet for an IPSec ESP transport
 + * enabled session should be the clear text packet with
 + * no ESP headers/trailers prepared in advance for crypto operation.
 + * The output packet will have ESP header, IV, trailer and the ESP ICV
 + * added by crypto implementation.
 + * Depending on the particular capabilities of an implementation and
 + * the parameters enabled by application, the application may be
 + * partially or completely offloaded from IPSec protocol processing.
 + * For example, if an implementation does not support checksum
 + * update for IP header after adding ESP header the application
 + * should update after crypto IPSec operation.
 + *
 + * If an implementation does not support a particular set of
 + * arguments it should return error.
 + *
 + * @param session  Session handle
 + * @param ipsec_mode   IPSec protocol mode
 + * @param ipsec_proto  IPSec protocol
 + * @param ipsec_params IPSec parameters. Parameters which are not
 + * relevant for selected protocol  mode are
 ignored -
 + * e.g. outer_hdr/size set for ESP transport mode.
 + * @retval 0 on success
 + * @retval 0 on failure
 + */
 +int odp_crypto_session_config_ipsec(odp_crypto_session_t