Re: [lng-odp] [PATCH API-NEXT v12] Ipsec doc

[Github ODP bot]

Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 68
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:


Comment:
Clarified in v12. Thanks.

> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> This version of the PR was intended to match the changes in PR #256. I'll 
> revert these in the next version since it seems we're now content with the 
> original semantics.


>> JannePeltonen wrote
>> Maybe it is not useful to mention length here since it is only a prefetching 
>> hint.


>>> JannePeltonen wrote
>>> Maybe it should be made more clear somewhere that the synchronous 
>>> processing calls are allowed only in the synchronous operating mode and 
>>> asynchronous calls in asynchronous and inline operation mode (and inline 
>>> calls only in the inline mode).


 JannePeltonen wrote
 This dummy packet stuff is not yet (if ever?) part of the API spec. I 
 think this patch should be in sync with what is the current state of 
 api-next, which still uses the status event for indicating SA disable 
 completion.


> JannePeltonen wrote
> "This call" could be replaced with odp_ipsec_sa_disable() to make the 
> text more clear.


>> JannePeltonen wrote
>> I think this may give the impression that calling odp_ipsec_sa_disable() 
>> is optional, when in fact it is mandatory before odp_ipsec_sa_destroy().


>>> JannePeltonen wrote
>>> According to the API spec soft limit alerts do not need to be edge 
>>> triggered. The spec says: "It's implementation defined how many times 
>>> soft lifetime expiration is reported: only once, first N or all packets 
>>> following the limit crossing."


 JannePeltonen wrote
 Is it clear enough here that the mtu error bit 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

Bill Fischofer(Bill-Fischofer-Linaro) replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 437
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once 

Re: [lng-odp] ODPH_IPPROTO_ICMPv4

[Maxim Uvarov]

On 11/01/17 21:10, Liron Himi wrote:
> Hi,
> 
> When I try to use either 'ODPH_IPPROTO_ICMPv4' in my code then checkpatch is 
> failing on
> 'CHECK: Avoid CamelCase: '.
> 
> Are those kind of 'check' errors can be ignored?
> Maybe it will be better if you change 'ODPH_IPPROTO_ICMPv4' to 
> 'ODPH_IPPROTO_ICMPV4' same as 'ODPH_ETHTYPE_IPV4'.
> 
> Thanks,
> Liron
> 

yes, it's better to change. We might skipped this on review.

Maxim.

[lng-odp] ODPH_IPPROTO_ICMPv4

[Liron Himi]

Hi,

When I try to use either 'ODPH_IPPROTO_ICMPv4' in my code then checkpatch is 
failing on
'CHECK: Avoid CamelCase: '.

Are those kind of 'check' errors can be ignored?
Maybe it will be better if you change 'ODPH_IPPROTO_ICMPv4' to 
'ODPH_IPPROTO_ICMPV4' same as 'ODPH_ETHTYPE_IPV4'.

Thanks,
Liron

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 218
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 437
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 430
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 64
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:


Comment:
Maybe it should be made more clear somewhere that the synchronous processing 
calls are allowed only in the synchronous operating mode and asynchronous calls 
in asynchronous and inline operation mode (and inline calls only in the inline 
mode).

> JannePeltonen wrote
> This dummy packet stuff is not yet (if ever?) part of the API spec. I think 
> this patch should be in sync with what is the current state of api-next, 
> which still uses the status event for indicating SA disable completion.


>> JannePeltonen wrote
>> "This call" could be replaced with odp_ipsec_sa_disable() to make the text 
>> more clear.


>>> JannePeltonen wrote
>>> I think this may give the impression that calling odp_ipsec_sa_disable() is 
>>> optional, when in fact it is mandatory before odp_ipsec_sa_destroy().


 JannePeltonen wrote
 According to the API spec soft limit alerts do not need to be edge 
 triggered. The spec says: "It's implementation defined how many times soft 
 lifetime expiration is reported: only once, first N or all packets 
 following the limit crossing."


> JannePeltonen wrote
> Is it clear enough here that the mtu error bit is set only when MTU 
> checking was requested and not in case fragmentation offload was 
> requested?


>> JannePeltonen wrote
>> Same comment as for odp_ipsec_{in,out}(), the description of the return 
>> code is not correct.


>>> JannePeltonen wrote
>>> The return code does not tell whether the application of the SA was 
>>> successful but how many input packets were consumed by the operation. 
>>> The per-packet operation status is retrieved via 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 428
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 418
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 294
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 273
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 266
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 255
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 251
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] DDF discussions taking time

[Francois Ozog]

here is the code snippet I promised:

/* = */
/* Code snipets  */


/* --- */
/* enumerator stuf */

/* PCI enumerator module */

pci_enumerator_class_init
{
enumclass_register("pci"...);
Browse /sys/bus/pci to create pci_enumerators for each bus
}

pci_enumerator_init
{
/* Do nothing */
}

/* netmdev enumerator module */

netmdev_enumerator_class_init
{
enumclass_register("netmdev"...);
}

netmdev_enumerrator_init
{
/* Do nothing */
}


/* --- */
/* driver stuf */

virtionet_probe()
{
}

virtionet_init()
{
enumclass clazz = enumclass_get("pci");
enumclass_register(clazz, virtionet_probe);
}

r8169_probe()
{
}

r8169_init()
{
enumclass clazz = enumclass_get("netmdev");
enumclass_driver_register(clazz, r8169_probe);
}


/* --- */
/* ODP application */

/* = */
/* pktio_open("pci::04.0") execution flow */

/* in pktio_open */
-> enumclass clazz= enumclass_get("pci") /* pci obtained from all chars
before ":"
-> if clazz=NULL (because no ":" or because no enumclass found browse
through all known pktios (this is the current behavior)

->clazz->pktio_probe(clazz, "pci::04.0")

/* in pci_pktio_probe: */
--> try all registered drivers:
--> driver->probe(clazz, "pci::04.0")

/* in virtionet_probe: */
---> check if the specified string designate a virtio_net pci device, lets
assume yes
--->clazz->add_device(clazz, )
---> return pktio structure


/* = */
/* pktio_open("netmdev:enp4s0") execution flow */

/* in pktio_open */
-> enumclass clazz= enumclass_get("netmdev") /* netmdev obtained from all
chars before ":"
-> if clazz=NULL (because no ":" or because no enumclass found browse
through all known pktios (this is the current behavior)

->clazz->pktio_probe(clazz, "netmdev:enp4s0")

/* in netmdev_pktio_probe: */
--> check enp4s0 is a netmdev capable device
/* we may want to introduce an additional parameter to
enumclass_driver_register with a string to avoid browsing */
/* for PCI this may be useless as one driver may handle so many different
PCI IDs, so we may ignore this */
--> if yes, try all registered drivers:
--> driver->probe(clazz, "netmdev:enp4s0")

/* in r8169_probe: */
---> check if the specified string designate a r8169 device (readlink
driver in sysfs), lets assume yes
--->clazz->add_device(clazz, )
---> return pktio structure



An ODP application that want to get hotplug would call:

pktio_open("*:*") or pktio_open("pci:*")

This could be made blocking so that bottom line ODP API do not change but
an application can deal with those things. The blocking call would be done
in an odp_thread. Alternatively, we may want to have event based stuff. So
the pktio_open above would actually result in subscribing to events.


A "device" will have multiple interfaces and additional meta data not found
in ODP objects:
- NUMA node,
- pktio_interface
- MII management interface
- xyz interface

The non pkitio interfaces are required if we can't go the netmdev route:
we'll need to have control on things beyond packetio ops and we don't want
to have a pktio_ops that grows 200 callbacks.

For those who did not attend the DDF presentation (or for those who
forgot). A pluggable NIC/SmartNIC may have multiple ports and even a
configurable switch.

ODP may consider the multiple ports as totally independent entities, but
doing so we fail to leverage NIC/SmarNIC features. The classifier of those
NIC/SmartNIC may be programmed to autonomously forward say non HTTP traffic
from port A to port B while sending all HTTP traffic to host queues.
But this classifier may not forward to Port C of another SmartNIC.

So information about devices and their structures will be required. That is
the role of the DDF.

FF
FF

On 28 October 2017 at 00:01, Bill Fischofer 
wrote:

>
>
> On Fri, Oct 27, 2017 at 4:54 PM, Francois Ozog 
> wrote:
>
>>
>> Le ven. 27 oct. 2017 à 23:51, Bill Fischofer 
>> a écrit :
>>
>>> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog >> > wrote:
>>>

 Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
 honnappa.nagaraha...@linaro.org> a écrit :

> On 27 October 2017 at 13:35, Bill Fischofer  > wrote:
>
>>
>>
>> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog <
>> francois.o...@linaro.org> wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer <
>>> bill.fischo...@linaro.org> a écrit :
>>>
 The problem with scanning, especially in a VNF environment, is that
 (a) the application probably isn't authorized to to that

>>>
>>> nothing prevents scanning what is available for n the vm. "Scale up"
>>> Events are triggered when increasing resources (memory cpus Ethernet
>>> ports...)
>>>
>>> and (b) the application 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 216
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 226
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline
+operations.
+* Whether classification pipelining is supported (to be discussed below).
+
+In addition, capabilities also inform the application of the maximum number
+of destination queues and classification CoS targets supported. These
+will be discussed further later.
+
+ IPsec Operation Modes
+IPsec operates in one of three modes: Synchronous, Asynchronous, and Inline.
+
+ Lookaside Processing
+Synchronous and Asynchronous are types of _lookaside_ processing. In lookaside
+mode, the application receives (or creates) an IPsec packet and then uses ODP
+to perform one of two functions:
+
+* To decrypt an IPsec packet into a "normal" packet
+* To take a "normal" packet and encrypt it into an IPsec packet.
+
+This process may be performed _synchronously_ with the APIs `odp_ipsec_in()`
+(to decrypt) and `odp_ipsec_out()` (to encrypt). Upon return from these calls
+the requested packet transformation is complete, or an error return code
+indicates that it could not be performed (_e.g.,_ packet decryption failed).
+
+Synchronous processing may be preferred if the application has a large number
+of worker threads so that blocking any individual worker while IPsec processing
+is performed represents a reasonable design. The alternative is to use
+_asynchronous_ forms of these APIs:
+
+* `odp_ipsec_in_enq()` for decrypt
+* `odp_ipsec_out_enq()` for encrypt
+
+These simply pass packets to IPsec for processing. When this processing is
+complete, the resulting packets are sent to the completion queue associated
+with the SA used by the operation, serving as IPsec completion events as
+shown here:
+
+image::ipsec-lookaside.svg[align="center"]
+
+If the operation fails because SA lookup failed for inbound processing, then
+these result packets are sent to the default queue specified as part of the
+`odp_ipsec_inbound_config_t` used in the `odp_ipsec_config()` call.
+
+Following an asynchronous IPsec call, the worker thread moves on to process
+other events until the IPsec completion shows up. At that point the worker
+thread sees whether the operation was successful or not and continues
+processing for that packet. These events may be direct-polled with
+`odp_queue_deq()` if the completion queue was created as a plain queue, or
+processed via the ODP scheduler if the completion queue was created as a
+scheduled queue.
+
+ Inline Processing
+While lookaside processing offers flexibility, it still requires extra
+processing steps not required by modern hardware. To avoid this overhead
+ODP also offers _inline_ processing support for IPsec. In this mode the
+processing of IPsec packets on the RX and TX paths is fully offloaded as
+shown here:
+
+image::ipsec-inline.svg[align="center"]
+
+It is worth noting that, depending on the implementation and application
+needs, inline processing may be enabled only for one direction (inbound or
+outbound) or for both directions.
+
+On the receive side, once configured for inline 

Re: [lng-odp] [PATCH API-NEXT v10] Ipsec doc

[Github ODP bot]

JannePeltonen replied on github web page:

doc/users-guide/users-guide-ipsec.adoc
line 37
@@ -0,0 +1,443 @@
+== IPsec services
+
+In addition to general cryptographic services, ODP offers offload support for
+the IPsec protocol. IPsec is a general term referencing a suite of protocols
+and packet formats and as such a full discussion of IPsec is beyond the scope
+of this document. See https://tools.ietf.org/html/rfc4301[RFC 4301] and
+related RFCs for more detail. This section assumes the reader is already
+familiar with IPsec and focuses on explaining the ODP APIs that support it.
+
+ODP provides APIs for the following IPsec services:
+
+* General IPsec configuration
+* Security Association (SA) configuration and lifecycle management
+* Synchronous and Asynchronous IPsec lookaside processing
+* Inline processing for full IPsec RX and/or TX offload
+* Pipelining for RX traffic
+* Fragmentation support for TX traffic
+* IPsec event management
+
+=== IPsec Capabilities and Configuration
+As with other features, ODP provides APIs that permit applications to query
+platform-specific IPsec capabilities. The `odp_ipsec_capability()` API queries
+the general IPsec features available while the `odp_ipsec_cipher_capability()`
+and `odp_ipsec_auth_capability()` APIs provide detail on the range of
+cipher and authentication algorithms supported by IPsec on this platform.
+
+General IPsec capabilities that are reported include:
+
+* The IPsec operation modes supported by this implementation. Different
+operation modes may be _not supported_, _supported_, or _preferred_. A
+preferred form means that this mode takes advantage of hardware
+acceleration features to achieve best performance.
+* Whether IPsec AH processing is supported. All ODP platforms must provide
+support for IPsec ESP processing, however since AH is relatively rare, it
+may not be supported, or supported only via software emulation (_e.g.,_ be
+non-preferred).
+* Whether IPsec headers should be retained on decrypt for inbound inline


Comment:
This should be: "...can be retained..." instead of "...should be retained..." 
as this is a capability and application chooses whether it wants to retain the 
headers if the ODP is capable.

> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> I'd like to see us all make it a priority to close on #197 next week. I'll 
> post a doc update once we're all agreed on the precise semantics and 
> operation flow. So I'm fine with holding off merging this PR until then.


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> Any update here? @NikhilA-Linaro, @bala-manoharan  can you please comment 
>> wrt your implementations?


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> Well, we do not have #197 merged, so it is too early to depend on that.
>>> Also, frankly speaking, this `sa_disabled` warning inside 
>>> `odp_ipsec_result_t` is a backup plan. It is expected that most of the 
>>> implementations will report this as a proper `ODP_IPSEC_STATUS` event, 
>>> carrying this warning bit inside.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 OK, changed in v6.


> Dmitry Eremin-Solenikov(lumag) wrote:
> s/default //


>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> OK, corrected in v5.


>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>> In lookaside mode soft limit expiration is reported as `warn` part of 
>>> `ipsec_op_status` packet metadata.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 OK, in v4 I've added a new terminal state `SA_Expired` to the FSM and 
 have updated the doc to say "expired" rather than "disabled". From the 
 expired state the only valid operation is `odp_ipsec_sa_destroy()`.


> Dmitry Eremin-Solenikov(lumag) wrote:
> Yep. It is just not a 'disabled' state, because we have separate 
> definition for 'disabled SA'.


>> Dmitry Eremin-Solenikov(lumag) wrote:
>> IIRC, one can call it only once in NXP case. @NikhilA-Linaro, could 
>> you please comment?


>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> So how is this indicated in lookaside mode? The whole point of ODP 
>>> providing the limit support is so the application doesn't have to 
>>> track byte/packet counts itself, so it's expected that soft limit 
>>> overruns will happen as part of lookaside processing as well.


 Bill Fischofer(Bill-Fischofer-Linaro) wrote:
 If you let yourself run out of gas, the car can stop at 
 inconvenient times, which is why one pays attention to that low 
 fuel warning light. A hard limit is a hard limit. That's what 
 makes it hard. Any other definition seems confusingly fuzzy and 
 unnecessary.


> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
> I thought the restriction is that you can call this repeatedly as 
> long as an SA hasn't yet been created. I can 

[lng-odp] [PATCH v1 0/1] doc, linux-gen, include: drop incomplete drv interface

[Github ODP bot]

Driver interface at master branch is incomplete. Drop it for now.
API-next will receive update DDF framework separately.
Signed-off-by: Dmitry Eremin-Solenikov dmitry.ereminsoleni...@linaro.org

github
/** Email created from pull request 268 (lumag:drv-remove)
 ** https://github.com/Linaro/odp/pull/268
 ** Patch: https://github.com/Linaro/odp/pull/268.patch
 ** Base sha: 387b402c4f2fc0694b6e0fe68ee4be8a2bd42442
 ** Merge commit sha: 2c51bd51e01f13c7b5617fcf0271f272da3da6dc
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 140 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

[lng-odp] [PATCH v1 1/1] doc, linux-gen, include: drop incomplete drv interface

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Driver interface at master branch is incomplete. Drop it for now.
API-next will receive update DDF framework separately.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 268 (lumag:drv-remove)
 ** https://github.com/Linaro/odp/pull/268
 ** Patch: https://github.com/Linaro/odp/pull/268.patch
 ** Base sha: 387b402c4f2fc0694b6e0fe68ee4be8a2bd42442
 ** Merge commit sha: 2c51bd51e01f13c7b5617fcf0271f272da3da6dc
 **/
 doc/Makefile.am|  3 +-
 doc/application-api-guide/Doxyfile |  1 -
 doc/driver-api-guide/.gitignore|  1 -
 doc/driver-api-guide/Doxyfile  | 14 -
 doc/driver-api-guide/Makefile.am   |  5 --
 doc/driver-api-guide/odp.dox   | 20 --
 doc/implementers-guide/implementers-guide.adoc | 72 +-
 doc/m4/configure.m4|  3 +-
 include/odp/drv/spec/README|  4 --
 include/odp/drv/spec/compiler.h| 51 ---
 include/odp/drv/spec/std_types.h   | 40 
 include/odp_drv.h  | 27 
 platform/linux-generic/Makefile.am |  4 --
 platform/linux-generic/include/odp/drv/README  |  2 -
 platform/linux-generic/include/odp/drv/compiler.h  | 34 --
 platform/linux-generic/include/odp/drv/std_types.h | 42 -
 16 files changed, 17 insertions(+), 306 deletions(-)
 delete mode 100644 doc/driver-api-guide/.gitignore
 delete mode 100644 doc/driver-api-guide/Doxyfile
 delete mode 100644 doc/driver-api-guide/Makefile.am
 delete mode 100644 doc/driver-api-guide/odp.dox
 delete mode 100644 include/odp/drv/spec/README
 delete mode 100644 include/odp/drv/spec/compiler.h
 delete mode 100644 include/odp/drv/spec/std_types.h
 delete mode 100644 include/odp_drv.h
 delete mode 100644 platform/linux-generic/include/odp/drv/README
 delete mode 100644 platform/linux-generic/include/odp/drv/compiler.h
 delete mode 100644 platform/linux-generic/include/odp/drv/std_types.h

diff --git a/doc/Makefile.am b/doc/Makefile.am
index c6124f46a..708a294e7 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1,8 +1,7 @@
 SUBDIRS = \
application-api-guide \
helper-guide \
-   platform-api-guide \
-   driver-api-guide
+   platform-api-guide
 
 if user_guide
 SUBDIRS += implementers-guide users-guide process-guide
diff --git a/doc/application-api-guide/Doxyfile 
b/doc/application-api-guide/Doxyfile
index 9cb183c13..a2168a927 100644
--- a/doc/application-api-guide/Doxyfile
+++ b/doc/application-api-guide/Doxyfile
@@ -5,7 +5,6 @@ PROJECT_NUMBER = $(VERSION)
 PROJECT_LOGO = $(SRCDIR)/doc/images/ODP-Logo-HQ.svg
 INPUT = $(SRCDIR)/doc/application-api-guide \
$(SRCDIR)/include
-EXCLUDE_PATTERNS = drv* odp_drv.h
 EXAMPLE_PATH = $(SRCDIR)/example $(SRCDIR)
 PREDEFINED = __GNUC__ \
 "ODP_HANDLE_T(type)=odp_handle_t type"
diff --git a/doc/driver-api-guide/.gitignore b/doc/driver-api-guide/.gitignore
deleted file mode 100644
index 53752db25..0
--- a/doc/driver-api-guide/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-output
diff --git a/doc/driver-api-guide/Doxyfile b/doc/driver-api-guide/Doxyfile
deleted file mode 100644
index 680d1d428..0
--- a/doc/driver-api-guide/Doxyfile
+++ /dev/null
@@ -1,14 +0,0 @@
-@INCLUDE = $(SRCDIR)/doc/Doxyfile_common
-
-PROJECT_NAME = "Driver Interface (drv) Reference Manual"
-PROJECT_NUMBER = $(VERSION)
-PROJECT_LOGO = $(SRCDIR)/doc/images/ODP-Logo-HQ.svg
-INPUT = $(SRCDIR)/doc/driver-api-guide \
-   $(SRCDIR)/include/odp/drv \
-   $(SRCDIR)/include/odp_drv.h
-EXCLUDE_PATTERNS = drv* odp_drv.h
-EXAMPLE_PATH = $(SRCDIR)/example $(SRCDIR)
-PREDEFINED = __GNUC__ \
-"ODP_HANDLE_T(type)=odp_handle_t type" \
-odpdrv_bool_t=int
-WARNINGS = NO
diff --git a/doc/driver-api-guide/Makefile.am b/doc/driver-api-guide/Makefile.am
deleted file mode 100644
index 4fc4755d1..0
--- a/doc/driver-api-guide/Makefile.am
+++ /dev/null
@@ -1,5 +0,0 @@
-EXTRA_DIST = \
-odp.dox
-
-clean-local:
-   rm -rf output
diff --git a/doc/driver-api-guide/odp.dox b/doc/driver-api-guide/odp.dox
deleted file mode 100644
index 687a79e04..0
--- a/doc/driver-api-guide/odp.dox
+++ /dev/null
@@ -1,20 +0,0 @@
-/* Copyright (c) 2016, Linaro Limited
- * All rights reserved
- *
- * SPDX-License-Identifier: BSD-3-Clause
- */
-
-/**
- * @mainpage
- *
- * @section sec_1 Introduction
- *
- * OpenDataPlane (ODP) provides a driver interface
-
- *
- * @section contact Contact Details
- * - The main web site is http://www.opendataplane.org/
- * - The git repo is https://git.linaro.org/lng/odp.git
- * - Bug tracking is https://bugs.linaro.org/buglist.cgi?product=OpenDataPlane
- *
- */
diff --git 

Re: [lng-odp] drv api in api-next

[Maxim Uvarov]

as discussed today we will drop drv from master and api-next branch. 2.0
branch will need to revert this deletion commit.
So that drv will be in 2.0 before it's will be ready to merge to master.

Maxim.

Re: [lng-odp] drv api in api-next

[Honnappa Nagarahalli]

On 1 November 2017 at 03:17, Dmitry Eremin-Solenikov
 wrote:
> On 31/10/17 22:21, Honnappa Nagarahalli wrote:
>> But they are APIs, even though they were copied from Linux-generic. I
>> am thinking the discussion has already happened on why they should be
>> in API directory. Is there any reason to revert and restart the
>> discussion?
>
> They are used for 2.0, but are unused in linux-generic (at least in
> TigerMoth). I'd vote to remove incomplete drv_* headers from TM. They
> will come back through 2.0.
>
The changes in api-next are merged to 2.0 branch. If we remove them in
master/api-next, the automatic merge will remove them from 2.0 as
well.

>> On 30 October 2017 at 11:43, Maxim Uvarov  wrote:
>>> In api-next we have some drv apis which is a copy of linux-generic but
>>> with drv prefix. I'm thinking what to do with them for Tiger Moth. Or
>>> merge them or merge and revert. For now we do not use that api.
>>>
>>> Maxim.
>
>
> --
> With best wishes
> Dmitry

[lng-odp] [PATCH API-NEXT v5 12/13] linux-gen: ipsec: mark IPsec packets with errors with error flag

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Add new ipsec_err error flag, which is set by IPsec code if there was an
error during IPsec packet processing. This allow application code to
quickly check packets using odp_packet_has_error() function and use fast
path if there was none.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 .../linux-generic/include/odp_packet_internal.h|   1 +
 platform/linux-generic/odp_ipsec.c | 104 -
 2 files changed, 60 insertions(+), 45 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_internal.h 
b/platform/linux-generic/include/odp_packet_internal.h
index fed562aa3..9c8b48b0c 100644
--- a/platform/linux-generic/include/odp_packet_internal.h
+++ b/platform/linux-generic/include/odp_packet_internal.h
@@ -53,6 +53,7 @@ typedef union {
uint32_t ip_err:1;/**< IP error,  checks TBD */
uint32_t tcp_err:1;   /**< TCP error, checks TBD */
uint32_t udp_err:1;   /**< UDP error, checks TBD */
+   uint32_t ipsec_err:1; /**< IPsec error */
};
 } error_flags_t;
 
diff --git a/platform/linux-generic/odp_ipsec.c 
b/platform/linux-generic/odp_ipsec.c
index 74a1c5766..8101b00c6 100644
--- a/platform/linux-generic/odp_ipsec.c
+++ b/platform/linux-generic/odp_ipsec.c
@@ -286,6 +286,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
uint8_t  ip_ttl; /**< Saved IP TTL value */
uint16_t ip_frag_offset; /**< Saved IP flags value */
odp_crypto_packet_result_t crypto; /**< Crypto operation result */
+   odp_packet_hdr_t *pkt_hdr;
 
ODP_ASSERT(ODP_PACKET_OFFSET_INVALID != ip_offset);
ODP_ASSERT(NULL != ip);
@@ -301,7 +302,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
 
if (_ODP_IPV4HDR_IS_FRAGMENT(odp_be_to_cpu_16(ip->frag_offset))) {
status->error.proto = 1;
-   goto out;
+   goto err;
}
 
/* Check IP header for IPSec protocols and look it up */
@@ -311,7 +312,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
if (odp_packet_copy_to_mem(pkt, ipsec_offset,
   sizeof(esp), ) < 0) {
status->error.alg = 1;
-   goto out;
+   goto err;
}
 
if (ODP_IPSEC_SA_INVALID == sa) {
@@ -324,7 +325,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
ipsec_sa = _odp_ipsec_sa_lookup();
if (NULL == ipsec_sa) {
status->error.sa_lookup = 1;
-   goto out;
+   goto err;
}
} else {
ipsec_sa = _odp_ipsec_sa_use(sa);
@@ -332,7 +333,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
if (ipsec_sa->proto != ODP_IPSEC_ESP ||
ipsec_sa->spi != odp_be_to_cpu_32(esp.spi)) {
status->error.proto = 1;
-   goto out;
+   goto err;
}
}
 
@@ -342,7 +343,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
   ipsec_sa->esp_iv_len,
   iv + ipsec_sa->salt_length) < 0) {
status->error.alg = 1;
-   goto out;
+   goto err;
}
 
hdr_len = _ODP_ESPHDR_LEN + ipsec_sa->esp_iv_len;
@@ -376,7 +377,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
if (odp_packet_copy_to_mem(pkt, ipsec_offset,
   sizeof(ah), ) < 0) {
status->error.alg = 1;
-   goto out;
+   goto err;
}
 
if (ODP_IPSEC_SA_INVALID == sa) {
@@ -389,7 +390,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
ipsec_sa = _odp_ipsec_sa_lookup();
if (NULL == ipsec_sa) {
status->error.sa_lookup = 1;
-   goto out;
+   goto err;
}
} else {
ipsec_sa = _odp_ipsec_sa_use(sa);
@@ -397,7 +398,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
if (ipsec_sa->proto != ODP_IPSEC_AH ||

[lng-odp] [PATCH API-NEXT v5 13/13] validation: check that erroneous IPsec packets have error flag set

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Verify that odp_packet_has_error() returns true for IPsec packets with
error status in result.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 test/validation/api/ipsec/ipsec.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/test/validation/api/ipsec/ipsec.c 
b/test/validation/api/ipsec/ipsec.c
index 5883f23e2..045718594 100644
--- a/test/validation/api/ipsec/ipsec.c
+++ b/test/validation/api/ipsec/ipsec.c
@@ -739,6 +739,10 @@ void ipsec_check_in_one(const ipsec_test_part *part, 
odp_ipsec_sa_t sa)
CU_ASSERT_EQUAL(0, odp_ipsec_result(, pkto[i]));
CU_ASSERT_EQUAL(part->out[i].status.error.all,
result.status.error.all);
+   if (result.status.error.all)
+   CU_ASSERT(odp_packet_has_error(pkto[i]))
+   else
+   CU_ASSERT(!odp_packet_has_error(pkto[i]));
CU_ASSERT_EQUAL(suite_context.inbound_op_mode ==
ODP_IPSEC_OP_MODE_INLINE,
result.flag.inline_mode);
@@ -778,6 +782,10 @@ void ipsec_check_out_one(const ipsec_test_part *part, 
odp_ipsec_sa_t sa)
CU_ASSERT_EQUAL(0, odp_ipsec_result(, pkto[i]));
CU_ASSERT_EQUAL(part->out[i].status.error.all,
result.status.error.all);
+   if (result.status.error.all)
+   CU_ASSERT(odp_packet_has_error(pkto[i]))
+   else
+   CU_ASSERT(!odp_packet_has_error(pkto[i]));
CU_ASSERT_EQUAL(sa, result.sa);
CU_ASSERT_EQUAL(IPSEC_SA_CTX,
odp_ipsec_sa_context(sa));

[lng-odp] [PATCH API-NEXT v5 10/13] linux-gen: ipsec: support pipelining to cos_t

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 .../include/odp_classification_datamodel.h |  2 --
 .../linux-generic/include/odp_ipsec_internal.h |  7 
 platform/linux-generic/odp_ipsec.c | 37 --
 platform/linux-generic/odp_ipsec_sad.c | 16 +-
 4 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/platform/linux-generic/include/odp_classification_datamodel.h 
b/platform/linux-generic/include/odp_classification_datamodel.h
index a40541986..25c488497 100644
--- a/platform/linux-generic/include/odp_classification_datamodel.h
+++ b/platform/linux-generic/include/odp_classification_datamodel.h
@@ -22,8 +22,6 @@ extern "C" {
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 
diff --git a/platform/linux-generic/include/odp_ipsec_internal.h 
b/platform/linux-generic/include/odp_ipsec_internal.h
index 0a7f96256..81ecec08e 100644
--- a/platform/linux-generic/include/odp_ipsec_internal.h
+++ b/platform/linux-generic/include/odp_ipsec_internal.h
@@ -23,6 +23,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 
 
 /** @ingroup odp_ipsec
  *  @{
@@ -141,6 +142,7 @@ struct ipsec_sa_s {
odp_ipsec_lookup_mode_t lookup_mode;
odp_u32be_t lookup_dst_ip;
odp_atomic_u64_t antireplay;
+   cos_t   *cos;
} in;
 
struct {
@@ -229,6 +231,11 @@ int _odp_ipsec_sa_replay_update(ipsec_sa_t *ipsec_sa, 
uint32_t seq,
 int _odp_ipsec_try_inline(odp_packet_t pkt);
 
 /**
+ * Returns ODP IPsec configuration
+ */
+const odp_ipsec_config_t *_odp_ipsec_config_get(void);
+
+/**
  * @}
  */
 
diff --git a/platform/linux-generic/odp_ipsec.c 
b/platform/linux-generic/odp_ipsec.c
index 5bb8330cb..74a1c5766 100644
--- a/platform/linux-generic/odp_ipsec.c
+++ b/platform/linux-generic/odp_ipsec.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -30,6 +31,7 @@ int odp_ipsec_capability(odp_ipsec_capability_t *capa)
int rc;
odp_crypto_capability_t crypto_capa;
odp_queue_capability_t queue_capa;
+   odp_cls_capability_t cls_capa;
 
memset(capa, 0, sizeof(odp_ipsec_capability_t));
 
@@ -39,6 +41,7 @@ int odp_ipsec_capability(odp_ipsec_capability_t *capa)
capa->op_mode_inline_out = ODP_SUPPORT_PREFERRED;
 
capa->proto_ah = ODP_SUPPORT_YES;
+   capa->pipeline_cls = ODP_SUPPORT_YES;
 
capa->max_num_sa = ODP_CONFIG_IPSEC_SAS;
 
@@ -57,6 +60,12 @@ int odp_ipsec_capability(odp_ipsec_capability_t *capa)
 
capa->max_queues = queue_capa.max_queues;
 
+   rc = odp_cls_capability(_capa);
+   if (rc < 0)
+   return rc;
+
+   capa->max_cls_cos = cls_capa.max_cos;
+
return 0;
 }
 
@@ -95,6 +104,11 @@ int odp_ipsec_config(const odp_ipsec_config_t *config)
return 0;
 }
 
+const odp_ipsec_config_t *_odp_ipsec_config_get(void)
+{
+   return _config;
+}
+
 static odp_ipsec_packet_result_t *ipsec_pkt_result(odp_packet_t packet)
 {
ODP_ASSERT(ODP_EVENT_PACKET_IPSEC ==
@@ -1060,7 +1074,16 @@ int odp_ipsec_in_enq(const odp_packet_t pkt_in[], int 
num_in,
result->status = status;
if (NULL != ipsec_sa) {
result->sa = ipsec_sa->ipsec_sa_hdl;
-   queue = ipsec_sa->queue;
+   if (ipsec_sa->in.cos && !status.error.all) {
+   odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt);
+   const uint8_t *base = odp_packet_data(pkt);
+
+   queue = cls_pkt_get_queue(pkt_hdr,
+ ipsec_sa->in.cos,
+ base);
+   } else {
+   queue = ipsec_sa->queue;
+   }
} else {
result->sa = ODP_IPSEC_SA_INVALID;
queue = ipsec_config.inbound.default_queue;
@@ -1143,6 +1166,7 @@ int _odp_ipsec_try_inline(odp_packet_t pkt)
ipsec_sa_t *ipsec_sa;
odp_ipsec_packet_result_t *result;
odp_packet_hdr_t *pkt_hdr;
+   odp_queue_t queue;
 
memset(, 0, sizeof(status));
 
@@ -1160,10 +1184,19 @@ int _odp_ipsec_try_inline(odp_packet_t pkt)
memset(result, 0, sizeof(*result));
result->status = status;
result->sa = ipsec_sa->ipsec_sa_hdl;
+   

[lng-odp] [PATCH API-NEXT v5 11/13] validation: ipsec: add support for PIPELINE_CLS testing

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 test/validation/api/ipsec/ipsec.c   | 165 ++--
 test/validation/api/ipsec/ipsec.h   |   3 +
 test/validation/api/ipsec/ipsec_async.c |   1 +
 test/validation/api/ipsec/ipsec_inline_in.c |   1 +
 4 files changed, 159 insertions(+), 11 deletions(-)

diff --git a/test/validation/api/ipsec/ipsec.c 
b/test/validation/api/ipsec/ipsec.c
index 853bd88a9..5883f23e2 100644
--- a/test/validation/api/ipsec/ipsec.c
+++ b/test/validation/api/ipsec/ipsec.c
@@ -117,6 +117,35 @@ static void pktio_stop(odp_pktio_t pktio)
}
 }
 
+static odp_cos_t ipsec_cos_create(void)
+{
+   odp_cls_cos_param_t param;
+   odp_cos_t cos;
+
+   odp_cls_cos_param_init();
+   param.pool = suite_context.pool;
+   param.num_queue = 1;
+   param.queue = odp_queue_create("ipsec-cos-queue", NULL);
+
+   if (ODP_QUEUE_INVALID == param.queue)
+   return ODP_COS_INVALID;
+
+   cos = odp_cls_cos_create("ipsec-cos", );
+   if (ODP_COS_INVALID != cos)
+   suite_context.cos_queue = odp_cos_queue(cos);
+
+   return cos;
+}
+
+static void ipsec_cos_destroy(void)
+{
+   odp_queue_t queue = odp_cos_queue(suite_context.cos);
+
+   suite_context.cos_queue = ODP_QUEUE_INVALID;
+   odp_cos_destroy(suite_context.cos);
+   odp_queue_destroy(queue);
+}
+
 #define MAX_ALG_CAPA 32
 
 int ipsec_check(odp_bool_t ah,
@@ -147,6 +176,11 @@ int ipsec_check(odp_bool_t ah,
 ODP_SUPPORT_NO == capa.op_mode_inline_out))
return ODP_TEST_INACTIVE;
 
+   if (ODP_COS_INVALID != suite_context.cos &&
+   (capa.pipeline_cls == ODP_SUPPORT_NO ||
+capa.max_cls_cos < 1))
+   return ODP_TEST_INACTIVE;
+
if (ah && (ODP_SUPPORT_NO == capa.proto_ah))
return ODP_TEST_INACTIVE;
 
@@ -288,6 +322,11 @@ void ipsec_sa_param_fill(odp_ipsec_sa_param_t *param,
if (in)
param->inbound.lookup_mode = ODP_IPSEC_LOOKUP_SPI;
 
+   if (in && (ODP_COS_INVALID != suite_context.cos)) {
+   param->inbound.pipeline = ODP_IPSEC_PIPELINE_CLS;
+   param->inbound.dest_cos = suite_context.cos;
+   }
+
param->proto = ah ? ODP_IPSEC_AH :
ODP_IPSEC_ESP;
 
@@ -438,23 +477,53 @@ static int ipsec_send_in_one(const ipsec_test_part *part,
pkto, _out,
));
CU_ASSERT_EQUAL(num_out, part->out_pkt);
-   } else if (ODP_IPSEC_OP_MODE_ASYNC == suite_context.inbound_op_mode) {
+   } else if (ODP_IPSEC_OP_MODE_ASYNC == suite_context.inbound_op_mode &&
+  ODP_QUEUE_INVALID == suite_context.cos_queue) {
CU_ASSERT_EQUAL(1, odp_ipsec_in_enq(, 1, ));
 
-   for (i = 0; i < num_out; i++) {
-   odp_event_t event;
+   for (i = 0; i < num_out;) {
+   odp_event_t ev;
odp_event_subtype_t subtype;
 
-   do {
-   event = odp_queue_deq(suite_context.queue);
-   } while (event == ODP_EVENT_INVALID);
+   ev = odp_queue_deq(suite_context.queue);
+   if (ODP_EVENT_INVALID != ev) {
+   CU_ASSERT_EQUAL(ODP_EVENT_PACKET,
+   odp_event_types(ev, ));
+   CU_ASSERT_EQUAL(ODP_EVENT_PACKET_IPSEC,
+   subtype);
+   pkto[i++] = odp_ipsec_packet_from_event(ev);
+   }
+   }
+   } else if (ODP_IPSEC_OP_MODE_ASYNC == suite_context.inbound_op_mode &&
+  ODP_QUEUE_INVALID != suite_context.cos_queue) {
+   CU_ASSERT_EQUAL(1, odp_ipsec_in_enq(, 1, ));
 
-   CU_ASSERT_EQUAL(ODP_EVENT_PACKET,
-   odp_event_types(event, ));
-   CU_ASSERT_EQUAL(ODP_EVENT_PACKET_IPSEC, subtype);
-   pkto[i] = odp_ipsec_packet_from_event(event);
+   for (i = 0; i < num_out;) {
+   odp_event_t ev;
+   odp_event_subtype_t subtype;
+
+   ev = odp_queue_deq(suite_context.queue);
+   if (ODP_EVENT_INVALID != ev) {
+   CU_ASSERT_EQUAL(ODP_EVENT_PACKET,
+  

[lng-odp] [PATCH API-NEXT v5 9/13] linux-gen: classification: split cls_pkt_get_queue() function

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Separate function returning destination queue from cos_t instance.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 .../include/odp_classification_internal.h  |  7 +
 platform/linux-generic/odp_classification.c| 34 --
 2 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/platform/linux-generic/include/odp_classification_internal.h 
b/platform/linux-generic/include/odp_classification_internal.h
index 8882a7177..4cadb9bdb 100644
--- a/platform/linux-generic/include/odp_classification_internal.h
+++ b/platform/linux-generic/include/odp_classification_internal.h
@@ -42,6 +42,13 @@ int cls_classify_packet(pktio_entry_t *entry, const uint8_t 
*base,
odp_packet_hdr_t *pkt_hdr);
 
 /**
+ * @internal
+ * Select packet destination queue basing on provided cos entry
+ */
+odp_queue_t cls_pkt_get_queue(odp_packet_hdr_t *pkt_hdr, cos_t *cos,
+ const uint8_t *base);
+
+/**
 Packet IO classifier init
 
 This function does initialization of classifier object associated with pktio.
diff --git a/platform/linux-generic/odp_classification.c 
b/platform/linux-generic/odp_classification.c
index 6ece74fca..317caefbf 100644
--- a/platform/linux-generic/odp_classification.c
+++ b/platform/linux-generic/odp_classification.c
@@ -961,8 +961,7 @@ int cls_classify_packet(pktio_entry_t *entry, const uint8_t 
*base,
odp_packet_hdr_t *pkt_hdr)
 {
cos_t *cos;
-   uint32_t tbl_index;
-   uint32_t hash;
+   odp_queue_t queue;
 
packet_parse_reset(pkt_hdr);
packet_set_len(pkt_hdr, pkt_len);
@@ -979,20 +978,37 @@ int cls_classify_packet(pktio_entry_t *entry, const 
uint8_t *base,
return -EFAULT;
 
*pool = cos->s.pool;
+
pkt_hdr->p.input_flags.dst_queue = 1;
 
-   if (!cos->s.queue_group) {
-   pkt_hdr->dst_queue = queue_fn->from_ext(cos->s.queue);
-   return 0;
-   }
+   queue = cls_pkt_get_queue(pkt_hdr, cos, base);
+   pkt_hdr->dst_queue = queue_fn->from_ext(queue);
+
+   return 0;
+}
+
+/**
+ * Set packet destination queue basing on the cos
+ *
+ * @param cos
+ * @param pkt_hdr  Packet header
+ * @param base Packet data
+ */
+odp_queue_t cls_pkt_get_queue(odp_packet_hdr_t *pkt_hdr, cos_t *cos,
+ const uint8_t *base)
+{
+   uint32_t tbl_index;
+   uint32_t hash;
+
+   if (!cos->s.queue_group)
+   return cos->s.queue;
 
hash = packet_rss_hash(pkt_hdr, cos->s.hash_proto, base);
/* CLS_COS_QUEUE_MAX is a power of 2 */
hash = hash & (CLS_COS_QUEUE_MAX - 1);
tbl_index = (cos->s.index * CLS_COS_QUEUE_MAX) + hash;
-   pkt_hdr->dst_queue = queue_fn->from_ext(queue_grp_tbl->
-   s.queue[tbl_index]);
-   return 0;
+
+   return queue_grp_tbl->s.queue[tbl_index];
 }
 
 static uint32_t packet_rss_hash(odp_packet_hdr_t *pkt_hdr,

[lng-odp] [PATCH API-NEXT v5 8/13] linux-gen: classification: provide _odp_cos_get_entry() function

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Provide function mapping from odp_cos_t to internal cos_t type.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 .../include/odp_classification_datamodel.h |  4 +++
 platform/linux-generic/odp_classification.c| 33 +++---
 2 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/platform/linux-generic/include/odp_classification_datamodel.h 
b/platform/linux-generic/include/odp_classification_datamodel.h
index 29b39f9c3..a40541986 100644
--- a/platform/linux-generic/include/odp_classification_datamodel.h
+++ b/platform/linux-generic/include/odp_classification_datamodel.h
@@ -123,6 +123,10 @@ typedef union cos_u {
uint8_t pad[ROUNDUP_CACHE_LINE(sizeof(struct cos_s))];
 } cos_t;
 
+/**
+ * Get classification entry basing on the id
+ */
+cos_t *_odp_cos_get_entry(odp_cos_t cos_id);
 
 /**
 Packet Matching Rule
diff --git a/platform/linux-generic/odp_classification.c 
b/platform/linux-generic/odp_classification.c
index a5cba56a4..6ece74fca 100644
--- a/platform/linux-generic/odp_classification.c
+++ b/platform/linux-generic/odp_classification.c
@@ -302,8 +302,7 @@ odp_pmr_t alloc_pmr(pmr_t **pmr)
return ODP_PMR_INVAL;
 }
 
-static
-cos_t *get_cos_entry(odp_cos_t cos_id)
+cos_t *_odp_cos_get_entry(odp_cos_t cos_id)
 {
if (_odp_typeval(cos_id) >= CLS_COS_MAX_ENTRY ||
cos_id == ODP_COS_INVALID)
@@ -326,7 +325,7 @@ pmr_t *get_pmr_entry(odp_pmr_t pmr_id)
 
 int odp_cos_destroy(odp_cos_t cos_id)
 {
-   cos_t *cos = get_cos_entry(cos_id);
+   cos_t *cos = _odp_cos_get_entry(cos_id);
 
if (NULL == cos) {
ODP_ERR("Invalid odp_cos_t handle");
@@ -339,7 +338,7 @@ int odp_cos_destroy(odp_cos_t cos_id)
 
 int odp_cos_queue_set(odp_cos_t cos_id, odp_queue_t queue_id)
 {
-   cos_t *cos = get_cos_entry(cos_id);
+   cos_t *cos = _odp_cos_get_entry(cos_id);
 
if (cos == NULL) {
ODP_ERR("Invalid odp_cos_t handle");
@@ -353,7 +352,7 @@ int odp_cos_queue_set(odp_cos_t cos_id, odp_queue_t 
queue_id)
 
 odp_queue_t odp_cos_queue(odp_cos_t cos_id)
 {
-   cos_t *cos = get_cos_entry(cos_id);
+   cos_t *cos = _odp_cos_get_entry(cos_id);
 
if (!cos) {
ODP_ERR("Invalid odp_cos_t handle");
@@ -365,7 +364,7 @@ odp_queue_t odp_cos_queue(odp_cos_t cos_id)
 
 uint32_t odp_cls_cos_num_queue(odp_cos_t cos_id)
 {
-   cos_t *cos = get_cos_entry(cos_id);
+   cos_t *cos = _odp_cos_get_entry(cos_id);
 
if (!cos) {
ODP_ERR("Invalid odp_cos_t handle");
@@ -383,7 +382,7 @@ uint32_t odp_cls_cos_queues(odp_cos_t cos_id, odp_queue_t 
queue[],
uint32_t tbl_index;
uint32_t i;
 
-   cos  = get_cos_entry(cos_id);
+   cos  = _odp_cos_get_entry(cos_id);
if (!cos) {
ODP_ERR("Invalid odp_cos_t handle");
return 0;
@@ -403,7 +402,7 @@ uint32_t odp_cls_cos_queues(odp_cos_t cos_id, odp_queue_t 
queue[],
 
 int odp_cos_drop_set(odp_cos_t cos_id, odp_cls_drop_t drop_policy)
 {
-   cos_t *cos = get_cos_entry(cos_id);
+   cos_t *cos = _odp_cos_get_entry(cos_id);
 
if (!cos) {
ODP_ERR("Invalid odp_cos_t handle");
@@ -417,7 +416,7 @@ int odp_cos_drop_set(odp_cos_t cos_id, odp_cls_drop_t 
drop_policy)
 
 odp_cls_drop_t odp_cos_drop(odp_cos_t cos_id)
 {
-   cos_t *cos = get_cos_entry(cos_id);
+   cos_t *cos = _odp_cos_get_entry(cos_id);
 
if (!cos) {
ODP_ERR("Invalid odp_cos_t handle");
@@ -437,7 +436,7 @@ int odp_pktio_default_cos_set(odp_pktio_t pktio_in, 
odp_cos_t default_cos)
ODP_ERR("Invalid odp_pktio_t handle");
return -1;
}
-   cos = get_cos_entry(default_cos);
+   cos = _odp_cos_get_entry(default_cos);
if (cos == NULL) {
ODP_ERR("Invalid odp_cos_t handle");
return -1;
@@ -458,7 +457,7 @@ int odp_pktio_error_cos_set(odp_pktio_t pktio_in, odp_cos_t 
error_cos)
return -1;
}
 
-   cos = get_cos_entry(error_cos);
+   cos = _odp_cos_get_entry(error_cos);
if (cos == NULL) {
ODP_ERR("Invalid odp_cos_t handle");
return -1;
@@ -512,7 +511,7 @@ int odp_cos_with_l2_priority(odp_pktio_t pktio_in,
LOCK(_cos->lock);
/* Update the L2 QoS table*/
for (i = 0; i < num_qos; i++) {
-   cos = get_cos_entry(cos_table[i]);
+   cos = _odp_cos_get_entry(cos_table[i]);
if (cos != NULL) {
if (CLS_COS_MAX_L2_QOS > qos_table[i])
   

[lng-odp] [PATCH API-NEXT v5 6/13] linux-gen: ipsec: support replay window checks

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 platform/linux-generic/odp_ipsec.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/platform/linux-generic/odp_ipsec.c 
b/platform/linux-generic/odp_ipsec.c
index 55b60162d..5bb8330cb 100644
--- a/platform/linux-generic/odp_ipsec.c
+++ b/platform/linux-generic/odp_ipsec.c
@@ -42,6 +42,8 @@ int odp_ipsec_capability(odp_ipsec_capability_t *capa)
 
capa->max_num_sa = ODP_CONFIG_IPSEC_SAS;
 
+   capa->max_antireplay_ws = IPSEC_ANTIREPLAY_WS;
+
rc = odp_crypto_capability(_capa);
if (rc < 0)
return rc;
@@ -402,6 +404,12 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
ip->frag_offset = 0;
ip->ttl = 0;
 
+   aad.spi = ah.spi;
+   aad.seq_no = ah.seq_no;
+
+   param.aad.ptr = (uint8_t *)
+   param.aad.length = sizeof(aad);
+
param.auth_range.offset = ip_offset;
param.auth_range.length = odp_be_to_cpu_16(ip->tot_len);
param.hash_result_offset = ipsec_offset + _ODP_AHHDR_LEN;
@@ -412,6 +420,11 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
goto out;
}
 
+   if (_odp_ipsec_sa_replay_precheck(ipsec_sa,
+ odp_be_to_cpu_32(aad.seq_no),
+ status) < 0)
+   goto out;
+
if (_odp_ipsec_sa_stats_precheck(ipsec_sa, status) < 0)
goto out;
 
@@ -450,6 +463,11 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
if (_odp_ipsec_sa_stats_update(ipsec_sa, stats_length, status) < 0)
goto out;
 
+   if (_odp_ipsec_sa_replay_update(ipsec_sa,
+   odp_be_to_cpu_32(aad.seq_no),
+   status) < 0)
+   goto out;
+
ip_offset = odp_packet_l3_offset(pkt);
ip = odp_packet_l3_ptr(pkt, NULL);
ip_hdr_len = ipv4_hdr_len(ip);
@@ -814,6 +832,12 @@ static ipsec_sa_t *ipsec_out_single(odp_packet_t pkt,
ah.next_header = ip->proto;
ip->proto = _ODP_IPPROTO_AH;
 
+   aad.spi = ah.spi;
+   aad.seq_no = ah.seq_no;
+
+   param.aad.ptr = (uint8_t *)
+   param.aad.length = sizeof(aad);
+
odp_packet_copy_from_mem(pkt,
 ipsec_offset, _ODP_AHHDR_LEN,
 );

[lng-odp] [PATCH API-NEXT v5 7/13] validation: ipsec: add replay window checks

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 test/validation/api/ipsec/ipsec_test_in.c | 204 ++
 test/validation/api/ipsec/test_vectors.h  |  87 +
 2 files changed, 291 insertions(+)

diff --git a/test/validation/api/ipsec/ipsec_test_in.c 
b/test/validation/api/ipsec/ipsec_test_in.c
index 25fc00e11..598a83e3f 100644
--- a/test/validation/api/ipsec/ipsec_test_in.c
+++ b/test/validation/api/ipsec/ipsec_test_in.c
@@ -284,6 +284,202 @@ static void test_in_esp_null_sha256_tun(void)
ipsec_sa_destroy(sa);
 }
 
+static void test_in_ah_sha256_noreplay(void)
+{
+   odp_ipsec_sa_param_t param;
+   odp_ipsec_sa_t sa;
+
+   ipsec_sa_param_fill(,
+   true, true, 123, NULL,
+   ODP_CIPHER_ALG_NULL, NULL,
+   ODP_AUTH_ALG_SHA256_HMAC, _5a_256,
+   NULL);
+   param.inbound.antireplay_ws = 0;
+
+   sa = odp_ipsec_sa_create();
+
+   CU_ASSERT_NOT_EQUAL_FATAL(ODP_IPSEC_SA_INVALID, sa);
+
+   ipsec_test_part test = {
+   .pkt_in = _icmp_0_ah_sha256_1,
+   .out_pkt = 1,
+   .out = {
+   { .status.warn.all = 0,
+ .status.error.all = 0,
+ .pkt_out = _icmp_0 },
+   },
+   };
+
+   ipsec_test_part test_1235 = {
+   .pkt_in = _icmp_0_ah_sha256_1235,
+   .out_pkt = 1,
+   .out = {
+   { .status.warn.all = 0,
+ .status.error.all = 0,
+ .pkt_out = _icmp_0 },
+   },
+   };
+
+   ipsec_check_in_one(, sa);
+   ipsec_check_in_one(, sa);
+   ipsec_check_in_one(_1235, sa);
+   ipsec_check_in_one(, sa);
+
+   ipsec_sa_destroy(sa);
+}
+
+static void test_in_ah_sha256_replay(void)
+{
+   odp_ipsec_sa_param_t param;
+   odp_ipsec_sa_t sa;
+
+   ipsec_sa_param_fill(,
+   true, true, 123, NULL,
+   ODP_CIPHER_ALG_NULL, NULL,
+   ODP_AUTH_ALG_SHA256_HMAC, _5a_256,
+   NULL);
+   param.inbound.antireplay_ws = 32;
+
+   sa = odp_ipsec_sa_create();
+
+   CU_ASSERT_NOT_EQUAL_FATAL(ODP_IPSEC_SA_INVALID, sa);
+
+   ipsec_test_part test = {
+   .pkt_in = _icmp_0_ah_sha256_1,
+   .out_pkt = 1,
+   .out = {
+   { .status.warn.all = 0,
+ .status.error.all = 0,
+ .pkt_out = _icmp_0 },
+   },
+   };
+
+   ipsec_test_part test_repl = {
+   .pkt_in = _icmp_0_ah_sha256_1,
+   .out_pkt = 1,
+   .out = {
+   { .status.warn.all = 0,
+ .status.error.antireplay = 1,
+ .pkt_out = NULL },
+   },
+   };
+
+   ipsec_test_part test_1235 = {
+   .pkt_in = _icmp_0_ah_sha256_1235,
+   .out_pkt = 1,
+   .out = {
+   { .status.warn.all = 0,
+ .status.error.all = 0,
+ .pkt_out = _icmp_0 },
+   },
+   };
+
+   ipsec_check_in_one(, sa);
+   ipsec_check_in_one(_repl, sa);
+   ipsec_check_in_one(_1235, sa);
+   ipsec_check_in_one(_repl, sa);
+
+   ipsec_sa_destroy(sa);
+}
+
+static void test_in_esp_null_sha256_noreplay(void)
+{
+   odp_ipsec_sa_param_t param;
+   odp_ipsec_sa_t sa;
+
+   ipsec_sa_param_fill(,
+   true, false, 123, NULL,
+   ODP_CIPHER_ALG_NULL, NULL,
+   ODP_AUTH_ALG_SHA256_HMAC, _5a_256,
+   NULL);
+   param.inbound.antireplay_ws = 0;
+
+   sa = odp_ipsec_sa_create();
+
+   CU_ASSERT_NOT_EQUAL_FATAL(ODP_IPSEC_SA_INVALID, sa);
+
+   ipsec_test_part test = {
+   .pkt_in = _icmp_0_esp_null_sha256_1,
+   .out_pkt = 1,
+   .out = {
+   { .status.warn.all = 0,
+ .status.error.all = 0,
+ .pkt_out = _icmp_0 },
+   },
+   };
+
+   ipsec_test_part test_1235 = {
+   .pkt_in = _icmp_0_esp_null_sha256_1235,
+   .out_pkt = 1,
+   .out = {
+   { .status.warn.all = 0,
+ .status.error.all = 0,
+ .pkt_out = _icmp_0 },
+

[lng-odp] [PATCH API-NEXT v5 4/13] linux-gen: ipsec: fix soft/hard limits check

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Split count expiration check into two phases:
 - optional precheck, run before crypto, which fails only if hard limit
   is already breached
 - update, run after crypto in INBOUND case, so that limits will not be
   updated for packets failing ICV check.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 .../linux-generic/include/odp_ipsec_internal.h | 10 +-
 platform/linux-generic/odp_ipsec.c | 12 +--
 platform/linux-generic/odp_ipsec_sad.c | 23 +-
 3 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/platform/linux-generic/include/odp_ipsec_internal.h 
b/platform/linux-generic/include/odp_ipsec_internal.h
index afc2f686e..68ab195c7 100644
--- a/platform/linux-generic/include/odp_ipsec_internal.h
+++ b/platform/linux-generic/include/odp_ipsec_internal.h
@@ -185,11 +185,19 @@ void _odp_ipsec_sa_unuse(ipsec_sa_t *ipsec_sa);
 ipsec_sa_t *_odp_ipsec_sa_lookup(const ipsec_sa_lookup_t *lookup);
 
 /**
+ * Run pre-check on SA usage statistics.
+ *
+ * @retval <0 if hard limits were breached
+ */
+int _odp_ipsec_sa_stats_precheck(ipsec_sa_t *ipsec_sa,
+odp_ipsec_op_status_t *status);
+
+/**
  * Update SA usage statistics, filling respective status for the packet.
  *
  * @retval <0 if hard limits were breached
  */
-int _odp_ipsec_sa_update_stats(ipsec_sa_t *ipsec_sa, uint32_t len,
+int _odp_ipsec_sa_stats_update(ipsec_sa_t *ipsec_sa, uint32_t len,
   odp_ipsec_op_status_t *status);
 
 /**
diff --git a/platform/linux-generic/odp_ipsec.c 
b/platform/linux-generic/odp_ipsec.c
index 1aa437b8e..55b60162d 100644
--- a/platform/linux-generic/odp_ipsec.c
+++ b/platform/linux-generic/odp_ipsec.c
@@ -412,9 +412,7 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
goto out;
}
 
-   if (_odp_ipsec_sa_update_stats(ipsec_sa,
-  stats_length,
-  status) < 0)
+   if (_odp_ipsec_sa_stats_precheck(ipsec_sa, status) < 0)
goto out;
 
param.session = ipsec_sa->session;
@@ -449,6 +447,9 @@ static ipsec_sa_t *ipsec_in_single(odp_packet_t pkt,
goto out;
}
 
+   if (_odp_ipsec_sa_stats_update(ipsec_sa, stats_length, status) < 0)
+   goto out;
+
ip_offset = odp_packet_l3_offset(pkt);
ip = odp_packet_l3_ptr(pkt, NULL);
ip_hdr_len = ipv4_hdr_len(ip);
@@ -835,9 +836,8 @@ static ipsec_sa_t *ipsec_out_single(odp_packet_t pkt,
goto out;
}
 
-   if (_odp_ipsec_sa_update_stats(ipsec_sa,
-  stats_length,
-  status) < 0)
+   /* No need to run precheck here, we know that packet is authentic */
+   if (_odp_ipsec_sa_stats_update(ipsec_sa, stats_length, status) < 0)
goto out;
 
param.session = ipsec_sa->session;
diff --git a/platform/linux-generic/odp_ipsec_sad.c 
b/platform/linux-generic/odp_ipsec_sad.c
index 5d20bb66c..fe8dfd0e4 100644
--- a/platform/linux-generic/odp_ipsec_sad.c
+++ b/platform/linux-generic/odp_ipsec_sad.c
@@ -476,7 +476,28 @@ ipsec_sa_t *_odp_ipsec_sa_lookup(const ipsec_sa_lookup_t 
*lookup)
return best;
 }
 
-int _odp_ipsec_sa_update_stats(ipsec_sa_t *ipsec_sa, uint32_t len,
+int _odp_ipsec_sa_stats_precheck(ipsec_sa_t *ipsec_sa,
+odp_ipsec_op_status_t *status)
+{
+   uint64_t bytes = odp_atomic_load_u64(_sa->bytes);
+   uint64_t packets = odp_atomic_load_u64(_sa->packets);
+   int rc = 0;
+
+   if (ipsec_sa->hard_limit_bytes > 0 &&
+   bytes > ipsec_sa->hard_limit_bytes) {
+   status->error.hard_exp_bytes = 1;
+   rc = -1;
+   }
+   if (ipsec_sa->hard_limit_packets > 0 &&
+   packets > ipsec_sa->hard_limit_packets) {
+   status->error.hard_exp_packets = 1;
+   rc = -1;
+   }
+
+   return rc;
+}
+
+int _odp_ipsec_sa_stats_update(ipsec_sa_t *ipsec_sa, uint32_t len,
   odp_ipsec_op_status_t *status)
 {
uint64_t bytes = odp_atomic_fetch_add_u64(_sa->bytes, len) + len;

[lng-odp] [PATCH API-NEXT v5 5/13] linux-gen: ipsec: add replay window support to SAD

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 .../linux-generic/include/odp_ipsec_internal.h | 20 
 platform/linux-generic/odp_ipsec_sad.c | 60 ++
 2 files changed, 80 insertions(+)

diff --git a/platform/linux-generic/include/odp_ipsec_internal.h 
b/platform/linux-generic/include/odp_ipsec_internal.h
index 68ab195c7..0a7f96256 100644
--- a/platform/linux-generic/include/odp_ipsec_internal.h
+++ b/platform/linux-generic/include/odp_ipsec_internal.h
@@ -81,6 +81,9 @@ int _odp_ipsec_status_send(odp_queue_t queue,
 
 #define IPSEC_MAX_SALT_LEN 4/**< Maximum salt length in bytes */
 
+/* 32 is minimum required by the standard. We do not support more */
+#define IPSEC_ANTIREPLAY_WS32
+
 /**
  * Maximum number of available SAs
  */
@@ -127,6 +130,9 @@ struct ipsec_sa_s {
 
/* Only for outbound */
unsigneduse_counter_iv : 1;
+
+   /* Only for inbound */
+   unsignedantireplay : 1;
};
};
 
@@ -134,6 +140,7 @@ struct ipsec_sa_s {
struct {
odp_ipsec_lookup_mode_t lookup_mode;
odp_u32be_t lookup_dst_ip;
+   odp_atomic_u64_t antireplay;
} in;
 
struct {
@@ -200,6 +207,19 @@ int _odp_ipsec_sa_stats_precheck(ipsec_sa_t *ipsec_sa,
 int _odp_ipsec_sa_stats_update(ipsec_sa_t *ipsec_sa, uint32_t len,
   odp_ipsec_op_status_t *status);
 
+/* Run pre-check on sequence number of the packet.
+ *
+ * @retval <0 if the packet falls out of window
+ */
+int _odp_ipsec_sa_replay_precheck(ipsec_sa_t *ipsec_sa, uint32_t seq,
+ odp_ipsec_op_status_t *status);
+
+/* Run check on sequence number of the packet and update window if necessary.
+ *
+ * @retval <0 if the packet falls out of window
+ */
+int _odp_ipsec_sa_replay_update(ipsec_sa_t *ipsec_sa, uint32_t seq,
+   odp_ipsec_op_status_t *status);
 /**
  * Try inline IPsec processing of provided packet.
  *
diff --git a/platform/linux-generic/odp_ipsec_sad.c 
b/platform/linux-generic/odp_ipsec_sad.c
index fe8dfd0e4..e010cfaa3 100644
--- a/platform/linux-generic/odp_ipsec_sad.c
+++ b/platform/linux-generic/odp_ipsec_sad.c
@@ -215,6 +215,10 @@ odp_ipsec_sa_t odp_ipsec_sa_create(const 
odp_ipsec_sa_param_t *param)
   param->inbound.lookup_param.dst_addr,
   sizeof(ipsec_sa->in.lookup_dst_ip));
 
+   if (param->inbound.antireplay_ws > IPSEC_ANTIREPLAY_WS)
+   return ODP_IPSEC_SA_INVALID;
+   ipsec_sa->antireplay = (param->inbound.antireplay_ws != 0);
+   odp_atomic_init_u64(_sa->in.antireplay, 0);
} else {
odp_atomic_store_u32(_sa->out.seq, 1);
}
@@ -525,3 +529,59 @@ int _odp_ipsec_sa_stats_update(ipsec_sa_t *ipsec_sa, 
uint32_t len,
 
return rc;
 }
+
+int _odp_ipsec_sa_replay_precheck(ipsec_sa_t *ipsec_sa, uint32_t seq,
+ odp_ipsec_op_status_t *status)
+{
+   /* Try to be as quick as possible, we will discard packets later */
+   if (ipsec_sa->antireplay &&
+   seq + IPSEC_ANTIREPLAY_WS <=
+   (odp_atomic_load_u64(_sa->in.antireplay) & 0x)) {
+   status->error.antireplay = 1;
+   return -1;
+   }
+
+   return 0;
+}
+
+int _odp_ipsec_sa_replay_update(ipsec_sa_t *ipsec_sa, uint32_t seq,
+   odp_ipsec_op_status_t *status)
+{
+   int cas = 0;
+   uint64_t state, new_state;
+
+   if (!ipsec_sa->antireplay)
+   return 0;
+
+   state = odp_atomic_load_u64(_sa->in.antireplay);
+
+   while (0 == cas) {
+   uint32_t max_seq = state & 0x;
+   uint32_t mask = state >> 32;
+
+   if (seq + IPSEC_ANTIREPLAY_WS <= max_seq) {
+   status->error.antireplay = 1;
+   return -1;
+   }
+
+   if (seq > max_seq) {
+   mask <<= seq - max_seq;
+   mask |= 1;
+   max_seq = seq;
+   } else {
+   if (mask & (1U << (max_seq - seq))) {
+   status->error.antireplay = 1;
+   return -1;
+   }
+
+   mask |= (1U << (max_seq - seq));
+   }
+
+  

[lng-odp] [PATCH API-NEXT v5 3/13] validation: ipsec: verify odp_ipsec_sa_context

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 test/validation/api/ipsec/ipsec.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/test/validation/api/ipsec/ipsec.c 
b/test/validation/api/ipsec/ipsec.c
index a8fdf2b14..853bd88a9 100644
--- a/test/validation/api/ipsec/ipsec.c
+++ b/test/validation/api/ipsec/ipsec.c
@@ -19,6 +19,9 @@ struct suite_context_s suite_context;
 #define PKT_POOL_NUM  64
 #define PKT_POOL_LEN  (1 * 1024)
 
+#define PACKET_USER_PTR((void *)0x1212fefe)
+#define IPSEC_SA_CTX   ((void *)0xfefefafa)
+
 static odp_pktio_t pktio_create(odp_pool_t pool)
 {
odp_pktio_t pktio;
@@ -300,6 +303,8 @@ void ipsec_sa_param_fill(odp_ipsec_sa_param_t *param,
 
param->dest_queue = suite_context.queue;
 
+   param->context = IPSEC_SA_CTX;
+
param->crypto.cipher_alg = cipher_alg;
if (cipher_key)
param->crypto.cipher_key = *cipher_key;
@@ -317,6 +322,8 @@ void ipsec_sa_destroy(odp_ipsec_sa_t sa)
odp_event_t event;
odp_ipsec_status_t status;
 
+   CU_ASSERT_EQUAL(IPSEC_SA_CTX, odp_ipsec_sa_context(sa));
+
CU_ASSERT_EQUAL(ODP_IPSEC_OK, odp_ipsec_sa_disable(sa));
 
if (ODP_QUEUE_INVALID != suite_context.queue) {
@@ -339,8 +346,6 @@ void ipsec_sa_destroy(odp_ipsec_sa_t sa)
CU_ASSERT_EQUAL(ODP_IPSEC_OK, odp_ipsec_sa_destroy(sa));
 }
 
-#define PACKET_USER_PTR((void *)0x1212fefe)
-
 odp_packet_t ipsec_packet(const ipsec_test_packet *itp)
 {
odp_packet_t pkt = odp_packet_alloc(suite_context.pool, itp->len);
@@ -608,7 +613,13 @@ void ipsec_check_in_one(const ipsec_test_part *part, 
odp_ipsec_sa_t sa)
CU_ASSERT_EQUAL(0, odp_ipsec_result(, pkto[i]));
CU_ASSERT_EQUAL(part->out[i].status.error.all,
result.status.error.all);
+   CU_ASSERT_EQUAL(suite_context.inbound_op_mode ==
+   ODP_IPSEC_OP_MODE_INLINE,
+   result.flag.inline_mode);
CU_ASSERT_EQUAL(sa, result.sa);
+   if (ODP_IPSEC_SA_INVALID != sa)
+   CU_ASSERT_EQUAL(IPSEC_SA_CTX,
+   odp_ipsec_sa_context(sa));
}
ipsec_check_packet(part->out[i].pkt_out,
   pkto[i]);
@@ -642,6 +653,8 @@ void ipsec_check_out_one(const ipsec_test_part *part, 
odp_ipsec_sa_t sa)
CU_ASSERT_EQUAL(part->out[i].status.error.all,
result.status.error.all);
CU_ASSERT_EQUAL(sa, result.sa);
+   CU_ASSERT_EQUAL(IPSEC_SA_CTX,
+   odp_ipsec_sa_context(sa));
}
ipsec_check_packet(part->out[i].pkt_out,
   pkto[i]);
@@ -679,6 +692,8 @@ void ipsec_check_out_in_one(const ipsec_test_part *part,
CU_ASSERT_EQUAL(part->out[i].status.error.all,
result.status.error.all);
CU_ASSERT_EQUAL(sa, result.sa);
+   CU_ASSERT_EQUAL(IPSEC_SA_CTX,
+   odp_ipsec_sa_context(sa));
}
CU_ASSERT_FATAL(odp_packet_len(pkto[i]) <=
sizeof(pkt_in.data));

[lng-odp] [PATCH API-NEXT v5 0/13] IPsec implementation updates

[Github ODP bot]

security fix for GCM mode: proper IV generation
implementation of 32-bit replay window support
implementation of PIPELINE_CLS support

github
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 77 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 0 lines checked


to_send-p-001.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 62 lines checked


to_send-p-002.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 79 lines checked


to_send-p-003.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 113 lines checked


to_send-p-004.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 54 lines checked


to_send-p-005.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 315 lines checked


to_send-p-006.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 133 lines checked


to_send-p-007.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 66 lines checked


to_send-p-008.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 151 lines checked


to_send-p-009.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 244 lines checked


to_send-p-010.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 338 lines checked


to_send-p-011.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 20 lines checked


to_send-p-012.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

[lng-odp] [PATCH API-NEXT v5 2/13] validation: ipsec: drop unused file

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 test/validation/api/ipsec/ipsec_sync_in.c | 27 ---
 1 file changed, 27 deletions(-)
 delete mode 100644 test/validation/api/ipsec/ipsec_sync_in.c

diff --git a/test/validation/api/ipsec/ipsec_sync_in.c 
b/test/validation/api/ipsec/ipsec_sync_in.c
deleted file mode 100644
index 8a7fc4680..0
--- a/test/validation/api/ipsec/ipsec_sync_in.c
+++ /dev/null
@@ -1,27 +0,0 @@
-/* Copyright (c) 2017, Linaro Limited
- * All rights reserved.
- *
- * SPDX-License-Identifier: BSD-3-Clause
- */
-
-#include "config.h"
-
-#include "ipsec.h"
-
-int main(int argc, char *argv[])
-{
-   int ret;
-
-   /* parse common options: */
-   if (odp_cunit_parse_options(argc, argv))
-   return -1;
-
-   odp_cunit_register_global_init(ipsec_init);
-   odp_cunit_register_global_term(ipsec_term);
-
-   ret = odp_cunit_register(ipsec_suites);
-   if (ret == 0)
-   ret = odp_cunit_run();
-
-   return ret;
-}

[lng-odp] [PATCH API-NEXT v5 1/13] linux-gen: ipsec: use counter instead of random IV for GCM

[Github ODP bot]

From: Dmitry Eremin-Solenikov 

Reusing IV block with GCM results in disastrous consequences. Use
counter instead of random-generated IV to remove possibility for IV
reuse.

Signed-off-by: Dmitry Eremin-Solenikov 
---
/** Email created from pull request 243 (lumag:ipsec-packet-impl-3)
 ** https://github.com/Linaro/odp/pull/243
 ** Patch: https://github.com/Linaro/odp/pull/243.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 636bc4f4108f651355ad9bbb9e7820bd9fc754e7
 **/
 platform/linux-generic/include/odp_ipsec_internal.h | 16 +---
 platform/linux-generic/odp_ipsec.c  | 19 ++-
 platform/linux-generic/odp_ipsec_sad.c  |  6 ++
 3 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/platform/linux-generic/include/odp_ipsec_internal.h 
b/platform/linux-generic/include/odp_ipsec_internal.h
index 1340ca7bd..afc2f686e 100644
--- a/platform/linux-generic/include/odp_ipsec_internal.h
+++ b/platform/linux-generic/include/odp_ipsec_internal.h
@@ -118,9 +118,17 @@ struct ipsec_sa_s {
uint8_t salt[IPSEC_MAX_SALT_LEN];
uint32_tsalt_length;
 
-   unsigneddec_ttl : 1;
-   unsignedcopy_dscp : 1;
-   unsignedcopy_df : 1;
+   union {
+   unsigned flags;
+   struct {
+   unsigneddec_ttl : 1;
+   unsignedcopy_dscp : 1;
+   unsignedcopy_df : 1;
+
+   /* Only for outbound */
+   unsigneduse_counter_iv : 1;
+   };
+   };
 
union {
struct {
@@ -136,6 +144,8 @@ struct ipsec_sa_s {
odp_atomic_u32_t tun_hdr_id;
odp_atomic_u32_t seq;
 
+   odp_atomic_u64_t counter; /* for CTR/GCM */
+
uint8_t tun_ttl;
uint8_t tun_dscp;
uint8_t tun_df;
diff --git a/platform/linux-generic/odp_ipsec.c 
b/platform/linux-generic/odp_ipsec.c
index e57736c2a..1aa437b8e 100644
--- a/platform/linux-generic/odp_ipsec.c
+++ b/platform/linux-generic/odp_ipsec.c
@@ -676,7 +676,24 @@ static ipsec_sa_t *ipsec_out_single(odp_packet_t pkt,
   ip_data_len +
   ipsec_sa->icv_len;
 
-   if (ipsec_sa->esp_iv_len) {
+   if (ipsec_sa->use_counter_iv) {
+   uint64_t ctr;
+
+   /* Both GCM and CTR use 8-bit counters */
+   ODP_ASSERT(sizeof(ctr) == ipsec_sa->esp_iv_len);
+
+   ctr = odp_atomic_fetch_add_u64(_sa->out.counter,
+  1);
+   /* Check for overrun */
+   if (ctr == 0)
+   goto out;
+
+   memcpy(iv, ipsec_sa->salt, ipsec_sa->salt_length);
+   memcpy(iv + ipsec_sa->salt_length, ,
+  ipsec_sa->esp_iv_len);
+
+   param.override_iv_ptr = iv;
+   } else if (ipsec_sa->esp_iv_len) {
uint32_t len;
 
len = odp_random_data(iv + ipsec_sa->salt_length,
diff --git a/platform/linux-generic/odp_ipsec_sad.c 
b/platform/linux-generic/odp_ipsec_sad.c
index f0b5b9e4a..5d20bb66c 100644
--- a/platform/linux-generic/odp_ipsec_sad.c
+++ b/platform/linux-generic/odp_ipsec_sad.c
@@ -207,6 +207,7 @@ odp_ipsec_sa_t odp_ipsec_sa_create(const 
odp_ipsec_sa_param_t *param)
ipsec_sa->context = param->context;
ipsec_sa->queue = param->dest_queue;
ipsec_sa->mode = param->mode;
+   ipsec_sa->flags = 0;
if (ODP_IPSEC_DIR_INBOUND == param->dir) {
ipsec_sa->in.lookup_mode = param->inbound.lookup_mode;
if (ODP_IPSEC_LOOKUP_DSTADDR_SPI == ipsec_sa->in.lookup_mode)
@@ -315,6 +316,7 @@ odp_ipsec_sa_t odp_ipsec_sa_create(const 
odp_ipsec_sa_param_t *param)
case ODP_CIPHER_ALG_AES128_GCM:
 #endif
case ODP_CIPHER_ALG_AES_GCM:
+   ipsec_sa->use_counter_iv = 1;
ipsec_sa->esp_iv_len = 8;
ipsec_sa->esp_block_len = 16;
crypto_param.iv.length = 12;
@@ -323,6 +325,10 @@ odp_ipsec_sa_t odp_ipsec_sa_create(const 
odp_ipsec_sa_param_t *param)
return ODP_IPSEC_SA_INVALID;
}
 
+   if (1 == ipsec_sa->use_counter_iv &&
+   ODP_IPSEC_DIR_OUTBOUND == param->dir)
+   odp_atomic_init_u64(_sa->out.counter, 1);
+
crypto_param.auth_digest_len = ipsec_sa->icv_len;
 
if (param->crypto.cipher_key_extra.length) {

[lng-odp] [PATCH API-NEXT v2 1/2] linux-gen: chksum: implement checksum insertion override functions

[Github ODP bot]

From: Bogdan Pricope 

The functions set L3/L4 checksum override output flags on the packet.
Checksum calculation, if requested, is perfromed at packet output time,
depending on interface capabilities.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 245 (bogdanPricope:api_next_ovr_csum_ref_pr)
 ** https://github.com/Linaro/odp/pull/245
 ** Patch: https://github.com/Linaro/odp/pull/245.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 3ee6c4da5a3b375e5eb87b9e656668e4fd6c8d73
 **/
 platform/linux-generic/odp_packet.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/platform/linux-generic/odp_packet.c 
b/platform/linux-generic/odp_packet.c
index 3b2fac212..0ad1a9329 100644
--- a/platform/linux-generic/odp_packet.c
+++ b/platform/linux-generic/odp_packet.c
@@ -1284,6 +1284,22 @@ int odp_packet_l4_offset_set(odp_packet_t pkt, uint32_t 
offset)
return 0;
 }
 
+void odp_packet_l3_chksum_insert(odp_packet_t pkt, int insert)
+{
+   odp_packet_hdr_t *pkt_hdr = packet_hdr(pkt);
+
+   pkt_hdr->p.output_flags.l3_chksum_set = 1;
+   pkt_hdr->p.output_flags.l3_chksum = insert;
+}
+
+void odp_packet_l4_chksum_insert(odp_packet_t pkt, int insert)
+{
+   odp_packet_hdr_t *pkt_hdr = packet_hdr(pkt);
+
+   pkt_hdr->p.output_flags.l4_chksum_set = 1;
+   pkt_hdr->p.output_flags.l4_chksum = insert;
+}
+
 void odp_packet_flow_hash_set(odp_packet_t pkt, uint32_t flow_hash)
 {
odp_packet_hdr_t *pkt_hdr = packet_hdr(pkt);

[lng-odp] [PATCH API-NEXT v2 2/2] linux-gen: pktio: dpdk: implement checksum insertion override

[Github ODP bot]

From: Bogdan Pricope 

Add checksum insertion override functionality to dpdk pktio.
Override is applied based on L3/L4 checksum insert override output flags
from the packet.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 245 (bogdanPricope:api_next_ovr_csum_ref_pr)
 ** https://github.com/Linaro/odp/pull/245
 ** Patch: https://github.com/Linaro/odp/pull/245.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 3ee6c4da5a3b375e5eb87b9e656668e4fd6c8d73
 **/
 platform/linux-generic/pktio/dpdk.c | 41 +++--
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/platform/linux-generic/pktio/dpdk.c 
b/platform/linux-generic/pktio/dpdk.c
index 9782d60c4..301ca10cb 100644
--- a/platform/linux-generic/pktio/dpdk.c
+++ b/platform/linux-generic/pktio/dpdk.c
@@ -503,7 +503,11 @@ static inline uint16_t phdr_csum(odp_bool_t ipv4, void 
*l3_hdr,
return rte_ipv6_phdr_cksum(l3_hdr, ol_flags);
 }
 
+#define OL_TX_CHKSUM_PKT(_cfg, _capa, _proto, _ovr_set, _ovr) \
+   (_capa && _proto && (_ovr_set ? _ovr : _cfg))
+
 static inline void pkt_set_ol_tx(odp_pktout_config_opt_t *pktout_cfg,
+odp_pktout_config_opt_t *pktout_capa,
 odp_packet_hdr_t *pkt_hdr,
 struct rte_mbuf *mbuf,
 char *mbuf_data)
@@ -519,11 +523,21 @@ static inline void pkt_set_ol_tx(odp_pktout_config_opt_t 
*pktout_cfg,
if (check_proto(l3_hdr, _proto_v4, _proto))
return;
 
-   ipv4_chksum_pkt = pktout_cfg->bit.ipv4_chksum && l3_proto_v4;
-   udp_chksum_pkt =  pktout_cfg->bit.udp_chksum &&
-   (l4_proto == _ODP_IPPROTO_UDP);
-   tcp_chksum_pkt = pktout_cfg->bit.tcp_chksum &&
-   (l4_proto == _ODP_IPPROTO_TCP);
+   ipv4_chksum_pkt = OL_TX_CHKSUM_PKT(pktout_cfg->bit.ipv4_chksum,
+  pktout_capa->bit.ipv4_chksum,
+  l3_proto_v4,
+  pkt_p->output_flags.l3_chksum_set,
+  pkt_p->output_flags.l3_chksum);
+   udp_chksum_pkt =  OL_TX_CHKSUM_PKT(pktout_cfg->bit.udp_chksum,
+  pktout_capa->bit.udp_chksum,
+  (l4_proto == _ODP_IPPROTO_UDP),
+  pkt_p->output_flags.l4_chksum_set,
+  pkt_p->output_flags.l4_chksum);
+   tcp_chksum_pkt =  OL_TX_CHKSUM_PKT(pktout_cfg->bit.tcp_chksum,
+  pktout_capa->bit.tcp_chksum,
+  (l4_proto == _ODP_IPPROTO_TCP),
+  pkt_p->output_flags.l4_chksum_set,
+  pkt_p->output_flags.l4_chksum);
 
if (!ipv4_chksum_pkt && !udp_chksum_pkt && !tcp_chksum_pkt)
return;
@@ -566,6 +580,8 @@ static inline int pkt_to_mbuf(pktio_entry_t *pktio_entry,
char *data;
uint16_t pkt_len;
odp_pktout_config_opt_t *pktout_cfg = _entry->s.config.pktout;
+   odp_pktout_config_opt_t *pktout_capa =
+   _entry->s.pkt_dpdk.capa.config.pktout;
 
if (odp_unlikely((rte_pktmbuf_alloc_bulk(pkt_dpdk->pkt_pool,
 mbuf_table, num {
@@ -586,8 +602,8 @@ static inline int pkt_to_mbuf(pktio_entry_t *pktio_entry,
 
odp_packet_copy_to_mem(pkt_table[i], 0, pkt_len, data);
 
-   if (pktout_cfg->all_bits)
-   pkt_set_ol_tx(pktout_cfg,
+   if (pktout_capa->all_bits)
+   pkt_set_ol_tx(pktout_cfg, pktout_capa,
  odp_packet_hdr(pkt_table[i]),
  mbuf_table[i], data);
}
@@ -679,6 +695,8 @@ static inline int pkt_to_mbuf_zero(pktio_entry_t 
*pktio_entry,
 {
pkt_dpdk_t *pkt_dpdk = _entry->s.pkt_dpdk;
odp_pktout_config_opt_t *pktout_cfg = _entry->s.config.pktout;
+   odp_pktout_config_opt_t *pktout_capa =
+   _entry->s.pkt_dpdk.capa.config.pktout;
int i;
*copy_count = 0;
 
@@ -696,8 +714,8 @@ static inline int pkt_to_mbuf_zero(pktio_entry_t 
*pktio_entry,
   pkt_hdr->extra_type == PKT_EXTRA_TYPE_DPDK)) {
mbuf_update(mbuf, pkt_hdr, pkt_len);
 
-   if (pktout_cfg->all_bits)
-   pkt_set_ol_tx(pktout_cfg, pkt_hdr,
+   if (pktout_capa->all_bits)
+   pkt_set_ol_tx(pktout_cfg, pktout_capa, pkt_hdr,
  mbuf, odp_packet_data(pkt));
} else {
   

[lng-odp] [PATCH API-NEXT v2 0/2] Implement checksum insertion override for dpdk pktio

[Github ODP bot]

Implement checksum insertion override generic functions and processing for dpdk 
pktio.

github
/** Email created from pull request 245 (bogdanPricope:api_next_ovr_csum_ref_pr)
 ** https://github.com/Linaro/odp/pull/245
 ** Patch: https://github.com/Linaro/odp/pull/245.patch
 ** Base sha: d22c949cc466bf28de559855a1cb525740578137
 ** Merge commit sha: 3ee6c4da5a3b375e5eb87b9e656668e4fd6c8d73
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 22 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 84 lines checked


to_send-p-001.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

[lng-odp] [PATCH 2.0 v2 4/4] linux-gen: pktio: remove duplicate odp_packet_io_internal.h

[Github ODP bot]

From: Bogdan Pricope 

Enable utilization of linux-generic version of odp_packet_io_internal.h
for linux-dpdk platform. Subsequently, linux-dpdk version of
odp_packet_io_internal.h is removed.
This is part of an attempt to reduce the delta between linux-dpdk and
linux-generic platforms to permit integration of linux-dpdk pktios
in linux-generic.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 267 (bogdanPricope:2_0_pktio_internal_pr)
 ** https://github.com/Linaro/odp/pull/267
 ** Patch: https://github.com/Linaro/odp/pull/267.patch
 ** Base sha: ca1be967bd4f6aec7dc99b72de643718cb8a32b8
 ** Merge commit sha: 29fab9a6071107a8bb565ceee1837755d3ca1eee
 **/
 platform/linux-dpdk/Makefile.am|   2 +-
 .../linux-dpdk/include/odp_packet_io_internal.h| 157 -
 .../linux-generic/include/odp_packet_io_internal.h |   1 -
 platform/linux-generic/odp_packet_io.c |   1 +
 4 files changed, 2 insertions(+), 159 deletions(-)
 delete mode 100644 platform/linux-dpdk/include/odp_packet_io_internal.h

diff --git a/platform/linux-dpdk/Makefile.am b/platform/linux-dpdk/Makefile.am
index e2a0249df..596c7b784 100644
--- a/platform/linux-dpdk/Makefile.am
+++ b/platform/linux-dpdk/Makefile.am
@@ -199,7 +199,7 @@ noinst_HEADERS = \
  
${top_srcdir}/platform/linux-generic/include/odp_pktio_ops_socket.h \
  
${top_srcdir}/platform/linux-generic/include/odp_pktio_ops_loopback.h \
  
${top_srcdir}/platform/linux-generic/include/odp_name_table_internal.h \
- ${srcdir}/include/odp_packet_io_internal.h \
+ 
${top_srcdir}/platform/linux-generic/include/odp_packet_io_internal.h \
  ${srcdir}/include/odp_errno_define.h \
  
${top_srcdir}/platform/linux-generic/include/odp_packet_io_ring_internal.h \
  
${top_srcdir}/platform/linux-generic/include/odp_pkt_queue_internal.h \
diff --git a/platform/linux-dpdk/include/odp_packet_io_internal.h 
b/platform/linux-dpdk/include/odp_packet_io_internal.h
deleted file mode 100644
index 089ad38c5..0
--- a/platform/linux-dpdk/include/odp_packet_io_internal.h
+++ /dev/null
@@ -1,157 +0,0 @@
-/* Copyright (c) 2013, Linaro Limited
- * All rights reserved.
- *
- * SPDX-License-Identifier: BSD-3-Clause
- */
-
-/**
- * @file
- *
- * ODP packet IO - implementation internal
- */
-
-#ifndef ODP_PACKET_IO_INTERNAL_H_
-#define ODP_PACKET_IO_INTERNAL_H_
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#define PKTIO_MAX_QUEUES 64
-#include 
-
-/* Forward declaration */
-typedef union pktio_entry_u pktio_entry_t;
-#include 
-
-#define PKTIO_NAME_LEN 256
-
-#define PKTIN_INVALID  ((odp_pktin_queue_t) {ODP_PKTIO_INVALID, 0})
-#define PKTOUT_INVALID ((odp_pktout_queue_t) {ODP_PKTIO_INVALID, 0})
-
-struct pktio_entry {
-   const pktio_ops_module_t *ops;  /**< Implementation specific methods */
-   uint8_t ops_data[ODP_PKTIO_ODPS_DATA_MAX_SIZE]; /**< IO operation
-   specific data */
-   /* These two locks together lock the whole pktio device */
-   odp_ticketlock_t rxl;   /**< RX ticketlock */
-   odp_ticketlock_t txl;   /**< TX ticketlock */
-   int cls_enabled;/**< is classifier enabled */
-   odp_pktio_t handle; /**< pktio handle */
-   enum {
-   /* Not allocated */
-   PKTIO_STATE_FREE = 0,
-   /* Close pending on scheduler response. Next state after this
-* is PKTIO_STATE_FREE. */
-   PKTIO_STATE_CLOSE_PENDING,
-   /* Open in progress.
-  Marker for all active states following under. */
-   PKTIO_STATE_ACTIVE,
-   /* Open completed */
-   PKTIO_STATE_OPENED,
-   /* Start completed */
-   PKTIO_STATE_STARTED,
-   /* Stop pending on scheduler response */
-   PKTIO_STATE_STOP_PENDING,
-   /* Stop completed */
-   PKTIO_STATE_STOPPED
-   } state;
-   odp_pktio_config_t config;  /**< Device configuration */
-   classifier_t cls;   /**< classifier linked with this pktio*/
-   odp_pktio_stats_t stats;/**< statistic counters for pktio */
-   char name[PKTIO_NAME_LEN];  /**< name of pktio provided to
-  pktio_open() */
-   odp_pool_t pool;
-   odp_pktio_param_t param;
-
-   /* Storage for queue handles
-* Multi-queue support is pktio driver specific */
-   unsigned num_in_queue;
-   unsigned num_out_queue;
-
-   struct {
-   odp_queue_tqueue;
-   queue_tqueue_int;
-   

[lng-odp] [PATCH 2.0 v2 1/4] linux-gen: pktio: move socket stats function prototypes

[Github ODP bot]

From: Bogdan Pricope 

Move socket stats function prototypes from linux-generic version
of odp_packet_io_internal.h.
This is part of an attempt to remove from this header file all the
references to symbols implemented only in linux-generic platform
before enabling it for linux-dpdk platform as well.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 267 (bogdanPricope:2_0_pktio_internal_pr)
 ** https://github.com/Linaro/odp/pull/267
 ** Patch: https://github.com/Linaro/odp/pull/267.patch
 ** Base sha: ca1be967bd4f6aec7dc99b72de643718cb8a32b8
 ** Merge commit sha: 29fab9a6071107a8bb565ceee1837755d3ca1eee
 **/
 .../linux-generic/include/odp_packet_io_internal.h |  4 
 platform/linux-generic/pktio/common.c  | 10 +
 platform/linux-generic/pktio/common.h  | 25 ++
 3 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index b26a35d25..e078cc826 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -149,10 +149,6 @@ static inline void pktio_cls_enabled_set(pktio_entry_t 
*entry, int ena)
 
 int sysfs_stats(pktio_entry_t *pktio_entry,
odp_pktio_stats_t *stats);
-int sock_stats_fd(pktio_entry_t *pktio_entry,
- odp_pktio_stats_t *stats,
- int fd);
-int sock_stats_reset_fd(pktio_entry_t *pktio_entry, int fd);
 
 int pktin_poll_one(int pktio_index,
   int rx_queue,
diff --git a/platform/linux-generic/pktio/common.c 
b/platform/linux-generic/pktio/common.c
index 4c952e467..050d2d950 100644
--- a/platform/linux-generic/pktio/common.c
+++ b/platform/linux-generic/pktio/common.c
@@ -21,6 +21,11 @@
 #include 
 #include 
 
+/*
+ * ODP_PACKET_SOCKET_MMSG:
+ * ODP_PACKET_SOCKET_MMAP:
+ * ODP_PACKET_NETMAP:
+ */
 int sock_stats_reset_fd(pktio_entry_t *pktio_entry, int fd)
 {
int err = 0;
@@ -51,6 +56,11 @@ int sock_stats_reset_fd(pktio_entry_t *pktio_entry, int fd)
return err;
 }
 
+/*
+ * ODP_PACKET_SOCKET_MMSG:
+ * ODP_PACKET_SOCKET_MMAP:
+ * ODP_PACKET_NETMAP:
+ */
 int sock_stats_fd(pktio_entry_t *pktio_entry,
  odp_pktio_stats_t *stats,
  int fd)
diff --git a/platform/linux-generic/pktio/common.h 
b/platform/linux-generic/pktio/common.h
index 2940af143..025e1893d 100644
--- a/platform/linux-generic/pktio/common.h
+++ b/platform/linux-generic/pktio/common.h
@@ -78,4 +78,29 @@ int rss_conf_set_fd(int fd, const char *name,
  */
 void rss_conf_print(const odp_pktin_hash_proto_t *hash_proto);
 
+/**
+ * Get statistics for pktio entry
+ *
+ * @param pktio_entry Packet IO entry
+ * @param stats[out]  Output buffer for counters
+ * @param fd  Socket file descriptor
+ *
+ * @retval 0 on success
+ * @retval != 0 on failure
+ */
+int sock_stats_fd(pktio_entry_t *pktio_entry,
+ odp_pktio_stats_t *stats,
+ int fd);
+
+/**
+ * Reset statistics for pktio entry
+ *
+ * @param pktio_entry Packet IO entry
+ * @param fd  Socket file descriptor
+ *
+ * @retval  0 on success
+ * @retval != 0 on failure
+ */
+int sock_stats_reset_fd(pktio_entry_t *pktio_entry, int fd);
+
 #endif /*ODP_PKTIO_COMMON_H_*/

[lng-odp] [PATCH 2.0 v2 3/4] linux-gen: pktio: move SOCK_ERR_REPORT macro from odp_packet_io_internal.h

[Github ODP bot]

From: Bogdan Pricope 

Move SOCK_ERR_REPORT macro from linux-generic version of
odp_packet_io_internal.h to a common header file.
This is part of an attempt to cleanup linux-generic version of
odp_packet_io_internal.h from macros used only in linux-generic platform
before enabling it for linux-dpdk platform as well.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 267 (bogdanPricope:2_0_pktio_internal_pr)
 ** https://github.com/Linaro/odp/pull/267
 ** Patch: https://github.com/Linaro/odp/pull/267.patch
 ** Base sha: ca1be967bd4f6aec7dc99b72de643718cb8a32b8
 ** Merge commit sha: 29fab9a6071107a8bb565ceee1837755d3ca1eee
 **/
 platform/linux-generic/include/odp_packet_io_internal.h | 6 --
 platform/linux-generic/pktio/common.h   | 8 
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index 1302a59bf..a2e1fdd9c 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -42,12 +42,6 @@ typedef union pktio_entry_u pktio_entry_t;
 #define PKTIN_INVALID  ((odp_pktin_queue_t) {ODP_PKTIO_INVALID, 0})
 #define PKTOUT_INVALID ((odp_pktout_queue_t) {ODP_PKTIO_INVALID, 0})
 
-/** Determine if a socket read/write error should be reported. Transient errors
- *  that simply require the caller to retry are ignored, the _send/_recv APIs
- *  are non-blocking and it is the caller's responsibility to retry if the
- *  requested number of packets were not handled. */
-#define SOCK_ERR_REPORT(e) (e != EAGAIN && e != EWOULDBLOCK && e != EINTR)
-
 struct pktio_entry {
const pktio_ops_module_t *ops;  /**< Implementation specific methods */
uint8_t ops_data[ODP_PKTIO_ODPS_DATA_MAX_SIZE]; /**< IO operation
diff --git a/platform/linux-generic/pktio/common.h 
b/platform/linux-generic/pktio/common.h
index 025e1893d..2ea68f646 100644
--- a/platform/linux-generic/pktio/common.h
+++ b/platform/linux-generic/pktio/common.h
@@ -7,6 +7,14 @@
 #ifndef ODP_PKTIO_COMMON_H_
 #define ODP_PKTIO_COMMON_H_
 
+#include 
+
+/** Determine if a socket read/write error should be reported. Transient errors
+ *  that simply require the caller to retry are ignored, the _send/_recv APIs
+ *  are non-blocking and it is the caller's responsibility to retry if the
+ *  requested number of packets were not handled. */
+#define SOCK_ERR_REPORT(e) (e != EAGAIN && e != EWOULDBLOCK && e != EINTR)
+
 /**
  * Read the MTU from a packet socket
  */

[lng-odp] [PATCH 2.0 v2 2/4] linux-gen: pktio: move sysfs stats function prototype

[Github ODP bot]

From: Bogdan Pricope 

Move sysfs stats function prototype from linux-generic version
of odp_packet_io_internal.h to a new header file.
This is part of an attempt to remove from linux-generic version
of odp_packet_io_internal.h all the references to symbols implemented
only in linux-generic platform before enabling it for linux-dpdk
platform as well.

Signed-off-by: Bogdan Pricope 
---
/** Email created from pull request 267 (bogdanPricope:2_0_pktio_internal_pr)
 ** https://github.com/Linaro/odp/pull/267
 ** Patch: https://github.com/Linaro/odp/pull/267.patch
 ** Base sha: ca1be967bd4f6aec7dc99b72de643718cb8a32b8
 ** Merge commit sha: 29fab9a6071107a8bb565ceee1837755d3ca1eee
 **/
 platform/linux-generic/Makefile.am |  1 +
 .../linux-generic/include/odp_packet_io_internal.h |  3 ---
 platform/linux-generic/pktio/common.c  |  1 +
 platform/linux-generic/pktio/socket.c  |  1 +
 platform/linux-generic/pktio/socket_mmap.c |  1 +
 platform/linux-generic/pktio/sysfs.c   |  1 +
 platform/linux-generic/pktio/sysfs.h   | 23 ++
 7 files changed, 28 insertions(+), 3 deletions(-)
 create mode 100644 platform/linux-generic/pktio/sysfs.h

diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 277418142..db466dd2a 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -177,6 +177,7 @@ noinst_HEADERS = \
  ${srcdir}/include/odp_packet_io_ring_internal.h \
  ${srcdir}/pktio/ethtool.h \
  ${srcdir}/pktio/common.h \
+ ${srcdir}/pktio/sysfs.h \
  ${srcdir}/pktio/dpdk.h \
  ${srcdir}/include/odp_pktio_ops_ipc.h \
  ${srcdir}/include/odp_pktio_ops_loopback.h \
diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index e078cc826..1302a59bf 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -147,9 +147,6 @@ static inline void pktio_cls_enabled_set(pktio_entry_t 
*entry, int ena)
entry->s.cls_enabled = ena;
 }
 
-int sysfs_stats(pktio_entry_t *pktio_entry,
-   odp_pktio_stats_t *stats);
-
 int pktin_poll_one(int pktio_index,
   int rx_queue,
   odp_event_t evt_tbl[]);
diff --git a/platform/linux-generic/pktio/common.c 
b/platform/linux-generic/pktio/common.c
index 050d2d950..900dcbba2 100644
--- a/platform/linux-generic/pktio/common.c
+++ b/platform/linux-generic/pktio/common.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/platform/linux-generic/pktio/socket.c 
b/platform/linux-generic/pktio/socket.c
index 7481f4f7f..d9f85b29a 100644
--- a/platform/linux-generic/pktio/socket.c
+++ b/platform/linux-generic/pktio/socket.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/platform/linux-generic/pktio/socket_mmap.c 
b/platform/linux-generic/pktio/socket_mmap.c
index 67d2b9206..9b35d89fe 100644
--- a/platform/linux-generic/pktio/socket_mmap.c
+++ b/platform/linux-generic/pktio/socket_mmap.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/platform/linux-generic/pktio/sysfs.c 
b/platform/linux-generic/pktio/sysfs.c
index c3d4faea1..f674ac42c 100644
--- a/platform/linux-generic/pktio/sysfs.c
+++ b/platform/linux-generic/pktio/sysfs.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/platform/linux-generic/pktio/sysfs.h 
b/platform/linux-generic/pktio/sysfs.h
new file mode 100644
index 0..f8fe3072a
--- /dev/null
+++ b/platform/linux-generic/pktio/sysfs.h
@@ -0,0 +1,23 @@
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_PKTIO_SYSFS_H_
+#define ODP_PKTIO_SYSFS_H_
+
+/**
+ * Get statistics for a pktio entry
+ *
+ * @param pktio_entry Packet IO entry
+ * @param stats[out]  Output buffer for counters
+ *
+ * @retval 0 on success
+ * @retval != 0 on failure
+ */
+
+int sysfs_stats(pktio_entry_t *pktio_entry,
+   odp_pktio_stats_t *stats);
+
+#endif /* ODP_PKTIO_SYSFS_H_ */

[lng-odp] [PATCH 2.0 v2 0/4] Remove duplicate odp_packet_io_internal.h

[Github ODP bot]

Remove duplicate odp_packet_io_internal.h

github
/** Email created from pull request 267 (bogdanPricope:2_0_pktio_internal_pr)
 ** https://github.com/Linaro/odp/pull/267
 ** Patch: https://github.com/Linaro/odp/pull/267.patch
 ** Base sha: ca1be967bd4f6aec7dc99b72de643718cb8a32b8
 ** Merge commit sha: 29fab9a6071107a8bb565ceee1837755d3ca1eee
 **/
/github

checkpatch.pl
total: 0 errors, 0 warnings, 0 checks, 61 lines checked


to_send-p-000.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 67 lines checked


to_send-p-001.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 26 lines checked


to_send-p-002.patch has no obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 22 lines checked


to_send-p-003.patch has no obvious style problems and is ready for submission.
/checkpatch.pl

Re: [lng-odp] [PATCH 2.0 v1] Remove duplicate odp_packet_io_internal.h

[Github ODP bot]

bogdanPricope replied on github web page:

platform/linux-dpdk/include/odp_packet_io_internal.h
line 157
@@ -1,157 +0,0 @@
-/* Copyright (c) 2013, Linaro Limited
- * All rights reserved.
- *
- * SPDX-License-Identifier: BSD-3-Clause
- */
-
-/**
- * @file
- *
- * ODP packet IO - implementation internal
- */
-
-#ifndef ODP_PACKET_IO_INTERNAL_H_
-#define ODP_PACKET_IO_INTERNAL_H_
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#define PKTIO_MAX_QUEUES 64
-#include 
-
-/* Forward declaration */
-typedef union pktio_entry_u pktio_entry_t;
-#include 
-
-#define PKTIO_NAME_LEN 256
-
-#define PKTIN_INVALID  ((odp_pktin_queue_t) {ODP_PKTIO_INVALID, 0})
-#define PKTOUT_INVALID ((odp_pktout_queue_t) {ODP_PKTIO_INVALID, 0})
-
-struct pktio_entry {
-   const pktio_ops_module_t *ops;  /**< Implementation specific methods */
-   uint8_t ops_data[ODP_PKTIO_ODPS_DATA_MAX_SIZE]; /**< IO operation
-   specific data */
-   /* These two locks together lock the whole pktio device */
-   odp_ticketlock_t rxl;   /**< RX ticketlock */
-   odp_ticketlock_t txl;   /**< TX ticketlock */
-   int cls_enabled;/**< is classifier enabled */
-   odp_pktio_t handle; /**< pktio handle */
-   enum {
-   /* Not allocated */
-   PKTIO_STATE_FREE = 0,
-   /* Close pending on scheduler response. Next state after this
-* is PKTIO_STATE_FREE. */
-   PKTIO_STATE_CLOSE_PENDING,
-   /* Open in progress.
-  Marker for all active states following under. */
-   PKTIO_STATE_ACTIVE,
-   /* Open completed */
-   PKTIO_STATE_OPENED,
-   /* Start completed */
-   PKTIO_STATE_STARTED,
-   /* Stop pending on scheduler response */
-   PKTIO_STATE_STOP_PENDING,
-   /* Stop completed */
-   PKTIO_STATE_STOPPED
-   } state;
-   odp_pktio_config_t config;  /**< Device configuration */
-   classifier_t cls;   /**< classifier linked with this pktio*/
-   odp_pktio_stats_t stats;/**< statistic counters for pktio */
-   char name[PKTIO_NAME_LEN];  /**< name of pktio provided to
-  pktio_open() */
-   odp_pool_t pool;
-   odp_pktio_param_t param;
-
-   /* Storage for queue handles
-* Multi-queue support is pktio driver specific */
-   unsigned num_in_queue;
-   unsigned num_out_queue;
-
-   struct {
-   odp_queue_tqueue;
-   queue_tqueue_int;
-   odp_pktin_queue_t  pktin;
-   } in_queue[PKTIO_MAX_QUEUES];
-
-   struct {
-   odp_queue_tqueue;
-   odp_pktout_queue_t pktout;
-   } out_queue[PKTIO_MAX_QUEUES];
-};
-
-union pktio_entry_u {
-   struct pktio_entry s;
-   uint8_t pad[ROUNDUP_CACHE_LINE(sizeof(struct pktio_entry))];
-};
-
-typedef struct {
-   odp_spinlock_t lock;
-   pktio_entry_t entries[ODP_CONFIG_PKTIO_ENTRIES];
-} pktio_table_t;
-
-extern void *pktio_entry_ptr[];
-
-static inline int pktio_to_id(odp_pktio_t pktio)
-{
-   return _odp_typeval(pktio) - 1;
-}
-
-static inline pktio_entry_t *get_pktio_entry(odp_pktio_t pktio)
-{
-   if (odp_unlikely(pktio == ODP_PKTIO_INVALID))
-   return NULL;
-
-   if (odp_unlikely(_odp_typeval(pktio) > ODP_CONFIG_PKTIO_ENTRIES)) {
-   ODP_DBG("pktio limit %d/%d exceed\n",
-   _odp_typeval(pktio), ODP_CONFIG_PKTIO_ENTRIES);
-   return NULL;
-   }
-
-   return pktio_entry_ptr[pktio_to_id(pktio)];
-}
-
-static inline int pktio_cls_enabled(pktio_entry_t *entry)
-{
-   return entry->s.cls_enabled;
-}
-
-static inline void pktio_cls_enabled_set(pktio_entry_t *entry, int ena)
-{
-   entry->s.cls_enabled = ena;
-}
-
-/*
- * Dummy single queue implementations of multi-queue API
- */
-int single_input_queues_config(pktio_entry_t *entry,
-  const odp_pktin_queue_param_t *param);
-int single_output_queues_config(pktio_entry_t *entry,
-   const odp_pktout_queue_param_t *param);
-int single_recv_queue(pktio_entry_t *entry, int index, odp_packet_t packets[],
- int num);
-int single_send_queue(pktio_entry_t *entry, int index,
- const odp_packet_t packets[], int num);
-
-int pktin_poll_one(int pktio_index,
-  int rx_queue,
-  odp_event_t evt_tbl[]);
-int pktin_poll(int pktio_index, int num_queue, int index[]);
-void pktio_stop_finalize(int pktio_index);
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif


Comment:
Verbose commit logs added in v2

> nagarahalli wrote
> Agree. I understand the 

Re: [lng-odp] [PATCH API-NEXT v4] api: pool subparameters

[Github ODP bot]

NikhilA-Linaro replied on github web page:

include/odp/api/spec/pool.h
line 48
@@ -163,79 +172,133 @@ typedef struct odp_pool_capability_t {
 int odp_pool_capability(odp_pool_capability_t *capa);
 
 /**
+ * Packet pool subparameters
+ */
+typedef struct odp_pool_pkt_subparam_t {
+   /** Number of 'len' byte packets. */
+   uint32_t num;
+
+   /** Packet length in bytes */
+   uint32_t len;
+
+} odp_pool_pkt_subparam_t;
+
+/**
  * Pool parameters
- * Used to communicate pool creation options.
- * @note A single thread may not be able to allocate all 'num' elements
- * from the pool at any particular time, as other threads or hardware
- * blocks are allowed to keep some for caching purposes.
+ *
+ * A note for all pool types: a single thread may not be able to allocate all
+ * 'num' elements from the pool at any particular time, as implementations are
+ * allowed to store some elements (per thread and HW engine) for caching
+ * purposes.


Comment:
This limitation is implementation specific. Why API wants to impose a generic 
limitation of APIs

> NikhilA-Linaro wrote
> 1. Traditionally a  pool means - a fixed size memory chunks. In case of 
> packet buffer pool,  the buffers units are of single size. If you need packet 
> buffer pools of different size,  different packet buffers pools shall be 
> attached to packet io or other entity.
> 2. These sub parameters will create ambiguity when application allocates 
> different packets of different sizes. API needs to define the clear 
> requirement in that case.
> 3.  Providing info for SG allocations from application is implementation 
> specific. I don't think this suits for a common data plane API. 


https://github.com/Linaro/odp/pull/234#discussion_r148219575
updated_at 2017-11-01 09:55:26

Re: [lng-odp] [PATCH API-NEXT v4] api: pool subparameters

[Github ODP bot]

NikhilA-Linaro replied on github web page:

include/odp/api/spec/pool.h
line 212
@@ -163,79 +172,133 @@ typedef struct odp_pool_capability_t {
 int odp_pool_capability(odp_pool_capability_t *capa);
 
 /**
+ * Packet pool subparameters
+ */
+typedef struct odp_pool_pkt_subparam_t {
+   /** Number of 'len' byte packets. */
+   uint32_t num;
+
+   /** Packet length in bytes */
+   uint32_t len;
+
+} odp_pool_pkt_subparam_t;
+
+/**
  * Pool parameters
- * Used to communicate pool creation options.
- * @note A single thread may not be able to allocate all 'num' elements
- * from the pool at any particular time, as other threads or hardware
- * blocks are allowed to keep some for caching purposes.
+ *
+ * A note for all pool types: a single thread may not be able to allocate all
+ * 'num' elements from the pool at any particular time, as implementations are
+ * allowed to store some elements (per thread and HW engine) for caching
+ * purposes.
  */
 typedef struct odp_pool_param_t {
/** Pool type */
int type;
 
-   /** Variant parameters for different pool types */
-   union {
-   /** Parameters for buffer pools */
-   struct {
-   /** Number of buffers in the pool */
-   uint32_t num;
-
-   /** Buffer size in bytes. The maximum number of bytes
-   application will store in each buffer. */
-   uint32_t size;
-
-   /** Minimum buffer alignment in bytes. Valid values are
-   powers of two. Use 0 for default alignment.
-   Default will always be a multiple of 8. */
-   uint32_t align;
-   } buf;
-
-   /** Parameters for packet pools */
-   struct {
-   /** The number of packets that the pool must provide
-   that are packet length 'len' bytes or smaller.
-   The maximum value is defined by pool capability
-   pkt.max_num. */
-   uint32_t num;
-
-   /** Minimum packet length that the pool must provide
-   'num' packets. The number of packets may be less
-   than 'num' when packets are larger than 'len'.
-   The maximum value is defined by pool capability
-   pkt.max_len. Use 0 for default. */
-   uint32_t len;
-
-   /** Maximum packet length that will be allocated from
-   the pool. The maximum value is defined by pool
-   capability pkt.max_len. Use 0 for default (the
-   pool maximum). */
-   uint32_t max_len;
-
-   /** Minimum number of packet data bytes that are stored
-   in the first segment of a packet. The maximum value
-   is defined by pool capability pkt.max_seg_len.
-   Use 0 for default. */
-   uint32_t seg_len;
-
-   /** User area size in bytes. The maximum value is
-   defined by pool capability pkt.max_uarea_size.
-   Specify as 0 if no user area is needed. */
-   uint32_t uarea_size;
-
-   /** Minimum Headroom size in bytes. Each newly allocated
-   packet from the pool must have at least this much
-   headroom. The maximum value is defined by pool
-   capability pkt.max_headroom.
-   Use zero if headroom is not needed. */
-   uint32_t headroom;
-   } pkt;
-
-   /** Parameters for timeout pools */
-   struct {
-   /** Number of timeouts in the pool */
-   uint32_t num;
-   } tmo;
-   };
+   /** Parameters for buffer pools */
+   struct {
+   /** Number of buffers in the pool */
+   uint32_t num;
+
+   /** Buffer size in bytes. The maximum number of bytes
+*  application will store in each buffer.
+*/
+   uint32_t size;
+
+   /** Minimum buffer alignment in bytes. Valid values are
+*  powers of two. Use 0 for default alignment.
+*  Default will always be a multiple of 8.
+*/
+   uint32_t align;
+   } buf;
+
+   /** Parameters for packet pools */
+   struct {
+   /** Minimum number of 'len' byte packets.
+*
+*  The pool must contain at least this many packets that are
+*  'len' bytes or smaller. An implementation 

Re: [lng-odp] drv api in api-next

[Dmitry Eremin-Solenikov]

On 31/10/17 22:21, Honnappa Nagarahalli wrote:
> But they are APIs, even though they were copied from Linux-generic. I
> am thinking the discussion has already happened on why they should be
> in API directory. Is there any reason to revert and restart the
> discussion?

They are used for 2.0, but are unused in linux-generic (at least in
TigerMoth). I'd vote to remove incomplete drv_* headers from TM. They
will come back through 2.0.

> On 30 October 2017 at 11:43, Maxim Uvarov  wrote:
>> In api-next we have some drv apis which is a copy of linux-generic but
>> with drv prefix. I'm thinking what to do with them for Tiger Moth. Or
>> merge them or merge and revert. For now we do not use that api.
>>
>> Maxim.


-- 
With best wishes
Dmitry

Re: [lng-odp] [PATCH API-NEXT v3 0/3] api: ones complement metadata

[Savolainen, Petri (Nokia - FI/Espoo)]

Ping.

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Github ODP bot
> Sent: Thursday, October 26, 2017 3:00 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH API-NEXT v3 0/3] api: ones complement metadata
> 
> Added packet metadata for ones complement sum over IP
> payload in a packet. Some NICs calculate the sum
> during packet input (at least for IP fragments) and
> store the value into the packet descriptor. This offloads
> L4 checksum calculation for IP fragments as SW does not
> need sum all payload data, but just combine pre-calculated
> sums from packet descriptors and remove extra header fields
> from the sum.
> 
> github
> /** Email created from pull request 242 (psavol:next-checksum-metadata)
>  ** https://github.com/Linaro/odp/pull/242
>  ** Patch: https://github.com/Linaro/odp/pull/242.patch
>  ** Base sha: 63d92eb289261d1534b5b9e1e04291faa5e45d30
>  ** Merge commit sha: 5c16247e4ce2735df80c66f11dd9c9708e8c905f
>  **/
> /github
> 
> checkpatch.pl
> total: 0 errors, 0 warnings, 0 checks, 26 lines checked
> 
> 
> to_send-p-000.patch has no obvious style problems and is ready for
> submission.
> total: 0 errors, 0 warnings, 0 checks, 14 lines checked
> 
> 
> to_send-p-001.patch has no obvious style problems and is ready for
> submission.
> total: 0 errors, 0 warnings, 0 checks, 55 lines checked
> 
> 
> to_send-p-002.patch has no obvious style problems and is ready for
> submission.
> /checkpatch.pl

Re: [lng-odp] [PATCH API-NEXT v4 0/8] api: pool subparameters

[Savolainen, Petri (Nokia - FI/Espoo)]

Ping.

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Github ODP bot
> Sent: Friday, October 27, 2017 11:00 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH API-NEXT v4 0/8] api: pool subparameters
> 
> Added packet pool parameters for more fine grained pool
> configuration. The basic usage of the parameters is not changed,
> except that implementation may now round up 'num' by default.
> Application can limit the round up with new 'max_num' parameter.
> If application does not limit max_num (but is still interested on
> max_num value), it can check the new info.pkt.max_num.
> The new specification allows implementation to use sub-pools,
> also application is able to request e.g. this kind of pool:
>^
> |
> 
> max_num | - - - - - - - -
> |
> |   *
> NUM|   * *
> |   * * *
> | * * * * *
> | * * * * * *
> +--->
> LEN
> 
> github
> /** Email created from pull request 234 (psavol:next-pool-param)
>  ** https://github.com/Linaro/odp/pull/234
>  ** Patch: https://github.com/Linaro/odp/pull/234.patch
>  ** Base sha: d61d32590d1772b70b8dcd0d0ec44d29029d7443
>  ** Merge commit sha: 436021e0a0bff8bda38fa420ebbc4545c97a7fc8
>  **/
> /github
> 
> checkpatch.pl
> total: 0 errors, 0 warnings, 0 checks, 58 lines checked
> 
> 
> to_send-p-000.patch has no obvious style problems and is ready for
> submission.
> total: 0 errors, 0 warnings, 0 checks, 72 lines checked
> 
> 
> to_send-p-001.patch has no obvious style problems and is ready for
> submission.
> total: 0 errors, 0 warnings, 0 checks, 124 lines checked
> 
> 
> to_send-p-002.patch has no obvious style problems and is ready for
> submission.
> total: 0 errors, 0 warnings, 0 checks, 122 lines checked
> 
> 
> to_send-p-003.patch has no obvious style problems and is ready for
> submission.
> total: 0 errors, 0 warnings, 0 checks, 59 lines checked
> 
> 
> to_send-p-004.patch has no obvious style problems and is ready for
> submission.
> total: 0 errors, 0 warnings, 0 checks, 9 lines checked
> 
> 
> to_send-p-005.patch has no obvious style problems and is ready for
> submission.
> total: 0 errors, 0 warnings, 0 checks, 47 lines checked
> 
> 
> to_send-p-006.patch has no obvious style problems and is ready for
> submission.
> total: 0 errors, 0 warnings, 0 checks, 217 lines checked
> 
> 
> to_send-p-007.patch has no obvious style problems and is ready for
> submission.
> /checkpatch.pl