[dpdk-dev] [PATCH 0/2] add inline protocol support

[dpdk-dev] [PATCH 0/2] add inline protocol support

[Anoob Joseph]

The series adds inline protocol support in ipsec-secgw application.

First patch introduces changes in lib to enable applications to store and
retrieve a 64 bit cookie. This is required for inline protocol processed
ingress packets. For inline protocol processed ingress packets, the packet may
not have enough information to identify the security parameters with which
the packet was processed. In such cases, inline protocol mechanism could set
some metadata in the mbuf, which could be used to retrieve the cookie. Cookie
will be registered while creating the security session.

Second patch adds the support for inline protocol in ipsec-secgw application.

Anoob Joseph (2):
  lib/security: add support for saving app cookie
  examples/ipsec-secgw: add support for inline protocol

 examples/ipsec-secgw/esp.c                |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c        |  40 +++++++++-
 examples/ipsec-secgw/ipsec.c              | 123 +++++++++++++++++++++++++-----
 lib/librte_security/rte_security.c        |  26 +++++++
 lib/librte_security/rte_security.h        |  30 ++++++++
 lib/librte_security/rte_security_driver.h |  34 +++++++++
 6 files changed, 237 insertions(+), 22 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie

[Anoob Joseph]

In case of inline protocol processed ingress traffic, the packet may not
have enough information to determine the security parameters with which
the packet was processed. In such cases, the application could register
a cookie, which will be saved in the the security session.

As the ingress packets are received in the application, it will have
some metadata set in the mbuf. Application can pass this metadata to
"rte_security_session_get" API to retrieve the security session. Once
the security session is determined, another driver call with the
security session will give the application the cookie it had registered.

The cookie will be registered while creating the security session.
Without the cookie, the selector check (SP-SA check) for the incoming
IPsec traffic won't be possible in the application.

Application can choose what it should register as the cookie. It can
register SPI or a pointer to SA.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
 lib/librte_security/rte_security.c        | 26 +++++++++++++++++++++++
 lib/librte_security/rte_security.h        | 30 +++++++++++++++++++++++++++
 lib/librte_security/rte_security_driver.h | 34 +++++++++++++++++++++++++++++++
 3 files changed, 90 insertions(+)

diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
index 1227fca..1c706fe 100644
--- a/lib/librte_security/rte_security.c
+++ b/lib/librte_security/rte_security.c
@@ -98,6 +98,32 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
 	return ret;
 }
 
+struct rte_security_session *
+rte_security_session_get(struct rte_security_ctx *instance,
+			 uint64_t mdata)
+{
+	struct rte_security_session *sess = NULL;
+
+	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->session_get, NULL);
+	if (instance->ops->session_get(instance->device, mdata, &sess))
+		return NULL;
+
+	return sess;
+}
+
+uint64_t
+rte_security_cookie_get(struct rte_security_ctx *instance,
+			struct rte_security_session *sess)
+{
+	uint64_t cookie = 0;
+
+	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->cookie_get, 0);
+	if (instance->ops->cookie_get(instance->device, sess, &cookie))
+		return 0;
+
+	return cookie;
+}
+
 int
 rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 			      struct rte_security_session *sess,
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index 7e687d2..95f81ee 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -273,6 +273,8 @@ struct rte_security_session_conf {
 	/**< Configuration parameters for security session */
 	struct rte_crypto_sym_xform *crypto_xform;
 	/**< Security Session Crypto Transformations */
+	uint64_t cookie;
+	/**< Cookie registered by application */
 };
 
 struct rte_security_session {
@@ -327,6 +329,34 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
 			     struct rte_security_session *sess);
 
 /**
+ * Get the security session from the metadata set in mbuf.
+ *
+ * @param   instance	security instance
+ * @param   mdata	metadata set in mbuf during rx offload
+ * @return
+ *  - On success, pointer to session
+ *  - On failure, NULL
+ */
+struct rte_security_session *
+rte_security_session_get(struct rte_security_ctx *instance,
+			 uint64_t mdata);
+
+/**
+ * Get the cookie set by application while creating the session. This could be
+ * used to identify the SA associated with the session.
+ *
+ * @param   instance	security instance
+ * @param   sess	security session
+ *
+ * @return
+ *  - On success, cookie
+ *  - On failure, 0
+ */
+uint64_t
+rte_security_cookie_get(struct rte_security_ctx *instance,
+			struct rte_security_session *sess);
+
+/**
  *  Updates the buffer with device-specific defined metadata
  *
  * @param	instance	security instance
diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
index 997fbe7..f503be6a 100644
--- a/lib/librte_security/rte_security_driver.h
+++ b/lib/librte_security/rte_security_driver.h
@@ -107,6 +107,36 @@ typedef int (*security_session_stats_get_t)(void *device,
 		struct rte_security_stats *stats);
 
 /**
+ * Get the security session from the metadata set in mbuf.
+ *
+ * @param	device		Crypto/eth device pointer
+ * @param	mdata		Metadata set in mbuf during rx offload
+ * @param	sess		Pointer to return the security session retrieved
+ *
+ * @return
+ *  - Returns 0 if the security session was successfully retrieved.
+ *  - Returns -EINVAL if input parameters are invalid.
+ */
+typedef int (*security_session_get_t)(void *device,
+		uint64_t mdata,
+		struct rte_security_session **sess);
+
+/**
+ * Get the cookie associated with the security session.
+ *
+ * @param	device		Crypto/eth device pointer
+ * @param	sess		Security session
+ * @param	cookie		Cookie associated with the security session
+ *
+ * @return
+ *  - Returns 0 if the cookie was successfully retrieved.
+ *  - Returns -EINVAL if input parameters are invalid.
+ */
+typedef int (*security_cookie_get_t)(void *device,
+		struct rte_security_session *sess,
+		uint64_t *cookie);
+
+/**
  * Update the mbuf with provided metadata.
  *
  * @param	sess		Security session structure
@@ -143,6 +173,10 @@ struct rte_security_ops {
 	/**< Get security session statistics. */
 	security_session_destroy_t session_destroy;
 	/**< Clear a security sessions private data. */
+	security_session_get_t session_get;
+	/**< Get the security session associated with the metadata */
+	security_cookie_get_t cookie_get;
+	/**< Get the cookie associated with the security session */
 	security_set_pkt_metadata_t set_pkt_metadata;
 	/**< Update mbuf metadata. */
 	security_capabilities_get_t capabilities_get;
-- 
2.7.4

Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie

[Radu Nicolau]

Hi,


Why not have something similar to rte_security_set_pkt_metadata, for 
example:

void *
rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
                   struct rte_mbuf *mb);

and keep internally in the PMD all the required references. The returned 
value will be device-specific, so it's flexible enough to include 
anything required (just as void *params is in the set_pkt_metadata).

I think it will make a cleaner and more consistent implementation.


Regards,

Radu



On 11/20/2017 10:31 AM, Anoob Joseph wrote:
> In case of inline protocol processed ingress traffic, the packet may not
> have enough information to determine the security parameters with which
> the packet was processed. In such cases, the application could register
> a cookie, which will be saved in the the security session.
>
> As the ingress packets are received in the application, it will have
> some metadata set in the mbuf. Application can pass this metadata to
> "rte_security_session_get" API to retrieve the security session. Once
> the security session is determined, another driver call with the
> security session will give the application the cookie it had registered.
>
> The cookie will be registered while creating the security session.
> Without the cookie, the selector check (SP-SA check) for the incoming
> IPsec traffic won't be possible in the application.
>
> Application can choose what it should register as the cookie. It can
> register SPI or a pointer to SA.
>
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
>   lib/librte_security/rte_security.c        | 26 +++++++++++++++++++++++
>   lib/librte_security/rte_security.h        | 30 +++++++++++++++++++++++++++
>   lib/librte_security/rte_security_driver.h | 34 +++++++++++++++++++++++++++++++
>   3 files changed, 90 insertions(+)
>
> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> index 1227fca..1c706fe 100644
> --- a/lib/librte_security/rte_security.c
> +++ b/lib/librte_security/rte_security.c
> @@ -98,6 +98,32 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
>   	return ret;
>   }
>   
> +struct rte_security_session *
> +rte_security_session_get(struct rte_security_ctx *instance,
> +			 uint64_t mdata)
> +{
> +	struct rte_security_session *sess = NULL;
> +
> +	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->session_get, NULL);
> +	if (instance->ops->session_get(instance->device, mdata, &sess))
> +		return NULL;
> +
> +	return sess;
> +}
> +
> +uint64_t
> +rte_security_cookie_get(struct rte_security_ctx *instance,
> +			struct rte_security_session *sess)
> +{
> +	uint64_t cookie = 0;
> +
> +	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->cookie_get, 0);
> +	if (instance->ops->cookie_get(instance->device, sess, &cookie))
> +		return 0;
> +
> +	return cookie;
> +}
> +
>   int
>   rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>   			      struct rte_security_session *sess,
> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> index 7e687d2..95f81ee 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -273,6 +273,8 @@ struct rte_security_session_conf {
>   	/**< Configuration parameters for security session */
>   	struct rte_crypto_sym_xform *crypto_xform;
>   	/**< Security Session Crypto Transformations */
> +	uint64_t cookie;
> +	/**< Cookie registered by application */
>   };
>   
>   struct rte_security_session {
> @@ -327,6 +329,34 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
>   			     struct rte_security_session *sess);
>   
>   /**
> + * Get the security session from the metadata set in mbuf.
> + *
> + * @param   instance	security instance
> + * @param   mdata	metadata set in mbuf during rx offload
> + * @return
> + *  - On success, pointer to session
> + *  - On failure, NULL
> + */
> +struct rte_security_session *
> +rte_security_session_get(struct rte_security_ctx *instance,
> +			 uint64_t mdata);
> +
> +/**
> + * Get the cookie set by application while creating the session. This could be
> + * used to identify the SA associated with the session.
> + *
> + * @param   instance	security instance
> + * @param   sess	security session
> + *
> + * @return
> + *  - On success, cookie
> + *  - On failure, 0
> + */
> +uint64_t
> +rte_security_cookie_get(struct rte_security_ctx *instance,
> +			struct rte_security_session *sess);
> +
> +/**
>    *  Updates the buffer with device-specific defined metadata
>    *
>    * @param	instance	security instance
> diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
> index 997fbe7..f503be6a 100644
> --- a/lib/librte_security/rte_security_driver.h
> +++ b/lib/librte_security/rte_security_driver.h
> @@ -107,6 +107,36 @@ typedef int (*security_session_stats_get_t)(void *device,
>   		struct rte_security_stats *stats);
>   
>   /**
> + * Get the security session from the metadata set in mbuf.
> + *
> + * @param	device		Crypto/eth device pointer
> + * @param	mdata		Metadata set in mbuf during rx offload
> + * @param	sess		Pointer to return the security session retrieved
> + *
> + * @return
> + *  - Returns 0 if the security session was successfully retrieved.
> + *  - Returns -EINVAL if input parameters are invalid.
> + */
> +typedef int (*security_session_get_t)(void *device,
> +		uint64_t mdata,
> +		struct rte_security_session **sess);
> +
> +/**
> + * Get the cookie associated with the security session.
> + *
> + * @param	device		Crypto/eth device pointer
> + * @param	sess		Security session
> + * @param	cookie		Cookie associated with the security session
> + *
> + * @return
> + *  - Returns 0 if the cookie was successfully retrieved.
> + *  - Returns -EINVAL if input parameters are invalid.
> + */
> +typedef int (*security_cookie_get_t)(void *device,
> +		struct rte_security_session *sess,
> +		uint64_t *cookie);
> +
> +/**
>    * Update the mbuf with provided metadata.
>    *
>    * @param	sess		Security session structure
> @@ -143,6 +173,10 @@ struct rte_security_ops {
>   	/**< Get security session statistics. */
>   	security_session_destroy_t session_destroy;
>   	/**< Clear a security sessions private data. */
> +	security_session_get_t session_get;
> +	/**< Get the security session associated with the metadata */
> +	security_cookie_get_t cookie_get;
> +	/**< Get the cookie associated with the security session */
>   	security_set_pkt_metadata_t set_pkt_metadata;
>   	/**< Update mbuf metadata. */
>   	security_capabilities_get_t capabilities_get;

Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie

[Anoob]

Hi,

Having something like "get_pkt_metadata" should be fine for inline 
protocol usage. But we will still need a "get cookie" call to get the 
cookie, as the application would need something it can interpret.

And, even though it seems both are symmetric operations(get & set pkt 
metadata), there are some minor differences in what they would do. Set 
metadata would be setting metadata(udata64 member) in mbuf, while get 
metadata is not exactly returning metadata. We use the actual metadata 
to get something else(security session in the proposed patch). That was 
the primary motive for adding "session_get" API.

Thanks,
Anoob

On 11/20/2017 05:42 PM, Radu Nicolau wrote:
> Hi,
>
>
> Why not have something similar to rte_security_set_pkt_metadata, for 
> example:
>
> void *
> rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>                   struct rte_mbuf *mb);
>
> and keep internally in the PMD all the required references. The 
> returned value will be device-specific, so it's flexible enough to 
> include anything required (just as void *params is in the 
> set_pkt_metadata).
>
> I think it will make a cleaner and more consistent implementation.
>
>
> Regards,
>
> Radu
>
>
>
> On 11/20/2017 10:31 AM, Anoob Joseph wrote:
>> In case of inline protocol processed ingress traffic, the packet may not
>> have enough information to determine the security parameters with which
>> the packet was processed. In such cases, the application could register
>> a cookie, which will be saved in the the security session.
>>
>> As the ingress packets are received in the application, it will have
>> some metadata set in the mbuf. Application can pass this metadata to
>> "rte_security_session_get" API to retrieve the security session. Once
>> the security session is determined, another driver call with the
>> security session will give the application the cookie it had registered.
>>
>> The cookie will be registered while creating the security session.
>> Without the cookie, the selector check (SP-SA check) for the incoming
>> IPsec traffic won't be possible in the application.
>>
>> Application can choose what it should register as the cookie. It can
>> register SPI or a pointer to SA.
>>
>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> ---
>>   lib/librte_security/rte_security.c        | 26 +++++++++++++++++++++++
>>   lib/librte_security/rte_security.h        | 30 
>> +++++++++++++++++++++++++++
>>   lib/librte_security/rte_security_driver.h | 34 
>> +++++++++++++++++++++++++++++++
>>   3 files changed, 90 insertions(+)
>>
>> diff --git a/lib/librte_security/rte_security.c 
>> b/lib/librte_security/rte_security.c
>> index 1227fca..1c706fe 100644
>> --- a/lib/librte_security/rte_security.c
>> +++ b/lib/librte_security/rte_security.c
>> @@ -98,6 +98,32 @@ rte_security_session_destroy(struct 
>> rte_security_ctx *instance,
>>       return ret;
>>   }
>>   +struct rte_security_session *
>> +rte_security_session_get(struct rte_security_ctx *instance,
>> +             uint64_t mdata)
>> +{
>> +    struct rte_security_session *sess = NULL;
>> +
>> +    RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->session_get, NULL);
>> +    if (instance->ops->session_get(instance->device, mdata, &sess))
>> +        return NULL;
>> +
>> +    return sess;
>> +}
>> +
>> +uint64_t
>> +rte_security_cookie_get(struct rte_security_ctx *instance,
>> +            struct rte_security_session *sess)
>> +{
>> +    uint64_t cookie = 0;
>> +
>> +    RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->cookie_get, 0);
>> +    if (instance->ops->cookie_get(instance->device, sess, &cookie))
>> +        return 0;
>> +
>> +    return cookie;
>> +}
>> +
>>   int
>>   rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>>                     struct rte_security_session *sess,
>> diff --git a/lib/librte_security/rte_security.h 
>> b/lib/librte_security/rte_security.h
>> index 7e687d2..95f81ee 100644
>> --- a/lib/librte_security/rte_security.h
>> +++ b/lib/librte_security/rte_security.h
>> @@ -273,6 +273,8 @@ struct rte_security_session_conf {
>>       /**< Configuration parameters for security session */
>>       struct rte_crypto_sym_xform *crypto_xform;
>>       /**< Security Session Crypto Transformations */
>> +    uint64_t cookie;
>> +    /**< Cookie registered by application */
>>   };
>>     struct rte_security_session {
>> @@ -327,6 +329,34 @@ rte_security_session_destroy(struct 
>> rte_security_ctx *instance,
>>                    struct rte_security_session *sess);
>>     /**
>> + * Get the security session from the metadata set in mbuf.
>> + *
>> + * @param   instance    security instance
>> + * @param   mdata    metadata set in mbuf during rx offload
>> + * @return
>> + *  - On success, pointer to session
>> + *  - On failure, NULL
>> + */
>> +struct rte_security_session *
>> +rte_security_session_get(struct rte_security_ctx *instance,
>> +             uint64_t mdata);
>> +
>> +/**
>> + * Get the cookie set by application while creating the session. 
>> This could be
>> + * used to identify the SA associated with the session.
>> + *
>> + * @param   instance    security instance
>> + * @param   sess    security session
>> + *
>> + * @return
>> + *  - On success, cookie
>> + *  - On failure, 0
>> + */
>> +uint64_t
>> +rte_security_cookie_get(struct rte_security_ctx *instance,
>> +            struct rte_security_session *sess);
>> +
>> +/**
>>    *  Updates the buffer with device-specific defined metadata
>>    *
>>    * @param    instance    security instance
>> diff --git a/lib/librte_security/rte_security_driver.h 
>> b/lib/librte_security/rte_security_driver.h
>> index 997fbe7..f503be6a 100644
>> --- a/lib/librte_security/rte_security_driver.h
>> +++ b/lib/librte_security/rte_security_driver.h
>> @@ -107,6 +107,36 @@ typedef int (*security_session_stats_get_t)(void 
>> *device,
>>           struct rte_security_stats *stats);
>>     /**
>> + * Get the security session from the metadata set in mbuf.
>> + *
>> + * @param    device        Crypto/eth device pointer
>> + * @param    mdata        Metadata set in mbuf during rx offload
>> + * @param    sess        Pointer to return the security session 
>> retrieved
>> + *
>> + * @return
>> + *  - Returns 0 if the security session was successfully retrieved.
>> + *  - Returns -EINVAL if input parameters are invalid.
>> + */
>> +typedef int (*security_session_get_t)(void *device,
>> +        uint64_t mdata,
>> +        struct rte_security_session **sess);
>> +
>> +/**
>> + * Get the cookie associated with the security session.
>> + *
>> + * @param    device        Crypto/eth device pointer
>> + * @param    sess        Security session
>> + * @param    cookie        Cookie associated with the security session
>> + *
>> + * @return
>> + *  - Returns 0 if the cookie was successfully retrieved.
>> + *  - Returns -EINVAL if input parameters are invalid.
>> + */
>> +typedef int (*security_cookie_get_t)(void *device,
>> +        struct rte_security_session *sess,
>> +        uint64_t *cookie);
>> +
>> +/**
>>    * Update the mbuf with provided metadata.
>>    *
>>    * @param    sess        Security session structure
>> @@ -143,6 +173,10 @@ struct rte_security_ops {
>>       /**< Get security session statistics. */
>>       security_session_destroy_t session_destroy;
>>       /**< Clear a security sessions private data. */
>> +    security_session_get_t session_get;
>> +    /**< Get the security session associated with the metadata */
>> +    security_cookie_get_t cookie_get;
>> +    /**< Get the cookie associated with the security session */
>>       security_set_pkt_metadata_t set_pkt_metadata;
>>       /**< Update mbuf metadata. */
>>       security_capabilities_get_t capabilities_get;
>

Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie

[Radu Nicolau]

Hi


On 11/20/2017 3:32 PM, Anoob wrote:
> Hi,
>
> Having something like "get_pkt_metadata" should be fine for inline 
> protocol usage. But we will still need a "get cookie" call to get the 
> cookie, as the application would need something it can interpret.
Why can't you have a get_pkt_metadata that returns the "cookie" - which 
I would call it userdata or similar? What I'm trying to say is that we 
should try to keep it as generic as possible. For example, I wouldn't 
assume that the cookie is stored in pkt->udata64 in the application.

> And, even though it seems both are symmetric operations(get & set pkt 
> metadata), there are some minor differences in what they would do. Set 
> metadata would be setting metadata(udata64 member) in mbuf, while get 
> metadata is not exactly returning metadata. We use the actual metadata 
> to get something else(security session in the proposed patch). That 
> was the primary motive for adding "session_get" API.
What they do exactly is left to the PMD implementation. From the user's 
perspective, it does not matter.
There is no requirement that set pkt metadata will set the udata64 member.
>
> Thanks,
> Anoob
>
> On 11/20/2017 05:42 PM, Radu Nicolau wrote:
>> Hi,
>>
>>
>> Why not have something similar to rte_security_set_pkt_metadata, for 
>> example:
>>
>> void *
>> rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>                   struct rte_mbuf *mb);
>>
>> and keep internally in the PMD all the required references. The 
>> returned value will be device-specific, so it's flexible enough to 
>> include anything required (just as void *params is in the 
>> set_pkt_metadata).
>>
>> I think it will make a cleaner and more consistent implementation.
>>
>>
>> Regards,
>>
>> Radu
>>
>>
>>
>> On 11/20/2017 10:31 AM, Anoob Joseph wrote:
>>> In case of inline protocol processed ingress traffic, the packet may 
>>> not
>>> have enough information to determine the security parameters with which
>>> the packet was processed. In such cases, the application could register
>>> a cookie, which will be saved in the the security session.
>>>
>>> As the ingress packets are received in the application, it will have
>>> some metadata set in the mbuf. Application can pass this metadata to
>>> "rte_security_session_get" API to retrieve the security session. Once
>>> the security session is determined, another driver call with the
>>> security session will give the application the cookie it had 
>>> registered.
>>>
>>> The cookie will be registered while creating the security session.
>>> Without the cookie, the selector check (SP-SA check) for the incoming
>>> IPsec traffic won't be possible in the application.
>>>
>>> Application can choose what it should register as the cookie. It can
>>> register SPI or a pointer to SA.
>>>
>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>> ---
>>>   lib/librte_security/rte_security.c        | 26 
>>> +++++++++++++++++++++++
>>>   lib/librte_security/rte_security.h        | 30 
>>> +++++++++++++++++++++++++++
>>>   lib/librte_security/rte_security_driver.h | 34 
>>> +++++++++++++++++++++++++++++++
>>>   3 files changed, 90 insertions(+)
>>> <snip>
>

Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie

[Anoob Joseph]

Hi

See inline.

On 20-11-2017 23:19, Radu Nicolau wrote:
> Hi
>
>
> On 11/20/2017 3:32 PM, Anoob wrote:
>> Hi,
>>
>> Having something like "get_pkt_metadata" should be fine for inline 
>> protocol usage. But we will still need a "get cookie" call to get the 
>> cookie, as the application would need something it can interpret.
> Why can't you have a get_pkt_metadata that returns the "cookie" - 
> which I would call it userdata or similar? What I'm trying to say is 
> that we should try to keep it as generic as possible. For example, I 
> wouldn't assume that the cookie is stored in pkt->udata64 in the 
> application.
I agree to your suggestion. The only problem is in the asymmetry of how 
we would set the "cookie" (or userdata) and get it back. Right now we 
are passing this as a member in conf. Do you have any thoughts on that? 
For a more meaningful approach, we could pass this as another argument 
in create_session API. I was thinking of a scenario of supporting more 
items. So added it in the structure.

Naming is open for suggestions. I'll use userdata instead.
>> And, even though it seems both are symmetric operations(get & set pkt 
>> metadata), there are some minor differences in what they would do. 
>> Set metadata would be setting metadata(udata64 member) in mbuf, while 
>> get metadata is not exactly returning metadata. We use the actual 
>> metadata to get something else(security session in the proposed 
>> patch). That was the primary motive for adding "session_get" API.
> What they do exactly is left to the PMD implementation. From the 
> user's perspective, it does not matter.
> There is no requirement that set pkt metadata will set the udata64 
> member.
May be I misunderstood the terminology. "udata64" in mbuf was documented as

|RTE_STD_C11 union { void *userdata; /**< Can be used for external 
metadata */ uint64_t udata64; /**< Allow 8-byte userdata on 32-bit */ };|


I thought the metadata in set_pkt_metadata was coming from this. And we 
were setting this member itself in ixgbe driver.

But yes, it makes sense not to expose it that way. The API can take mbuf 
pointer and then, the PMD could dictate how it had set the metadata in 
rx path.

>>
>> Thanks,
>> Anoob
>>
>> On 11/20/2017 05:42 PM, Radu Nicolau wrote:
>>> Hi,
>>>
>>>
>>> Why not have something similar to rte_security_set_pkt_metadata, for 
>>> example:
>>>
>>> void *
>>> rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>                   struct rte_mbuf *mb);
>>>
>>> and keep internally in the PMD all the required references. The 
>>> returned value will be device-specific, so it's flexible enough to 
>>> include anything required (just as void *params is in the 
>>> set_pkt_metadata).
>>>
>>> I think it will make a cleaner and more consistent implementation.
>>>
>>>
>>> Regards,
>>>
>>> Radu
>>>
>>>
>>>
>>> On 11/20/2017 10:31 AM, Anoob Joseph wrote:
>>>> In case of inline protocol processed ingress traffic, the packet 
>>>> may not
>>>> have enough information to determine the security parameters with 
>>>> which
>>>> the packet was processed. In such cases, the application could 
>>>> register
>>>> a cookie, which will be saved in the the security session.
>>>>
>>>> As the ingress packets are received in the application, it will have
>>>> some metadata set in the mbuf. Application can pass this metadata to
>>>> "rte_security_session_get" API to retrieve the security session. Once
>>>> the security session is determined, another driver call with the
>>>> security session will give the application the cookie it had 
>>>> registered.
>>>>
>>>> The cookie will be registered while creating the security session.
>>>> Without the cookie, the selector check (SP-SA check) for the incoming
>>>> IPsec traffic won't be possible in the application.
>>>>
>>>> Application can choose what it should register as the cookie. It can
>>>> register SPI or a pointer to SA.
>>>>
>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>> ---
>>>>   lib/librte_security/rte_security.c        | 26 
>>>> +++++++++++++++++++++++
>>>>   lib/librte_security/rte_security.h        | 30 
>>>> +++++++++++++++++++++++++++
>>>>   lib/librte_security/rte_security_driver.h | 34 
>>>> +++++++++++++++++++++++++++++++
>>>>   3 files changed, 90 insertions(+)
>>>> <snip>
>>
>
I'll rework the patch to include your suggestions. I'll send a v2 after 
doing this.

Thanks for the feedback,
Anoob

Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie

[Radu Nicolau]

On 11/20/2017 7:09 PM, Anoob Joseph wrote:
>
> Hi
>
> See inline.
>
> On 20-11-2017 23:19, Radu Nicolau wrote:
>> Hi
>>
>>
>> On 11/20/2017 3:32 PM, Anoob wrote:
>>> Hi,
>>>
>>> Having something like "get_pkt_metadata" should be fine for inline 
>>> protocol usage. But we will still need a "get cookie" call to get 
>>> the cookie, as the application would need something it can interpret.
>> Why can't you have a get_pkt_metadata that returns the "cookie" - 
>> which I would call it userdata or similar? What I'm trying to say is 
>> that we should try to keep it as generic as possible. For example, I 
>> wouldn't assume that the cookie is stored in pkt->udata64 in the 
>> application.
> I agree to your suggestion. The only problem is in the asymmetry of 
> how we would set the "cookie" (or userdata) and get it back. Right now 
> we are passing this as a member in conf. Do you have any thoughts on 
> that? For a more meaningful approach, we could pass this as another 
> argument in create_session API. I was thinking of a scenario of 
> supporting more items. So added it in the structure.
>
> Naming is open for suggestions. I'll use userdata instead.
I think keeping it in the conf is best, but it can be either way.

>>> And, even though it seems both are symmetric operations(get & set 
>>> pkt metadata), there are some minor differences in what they would 
>>> do. Set metadata would be setting metadata(udata64 member) in mbuf, 
>>> while get metadata is not exactly returning metadata. We use the 
>>> actual metadata to get something else(security session in the 
>>> proposed patch). That was the primary motive for adding 
>>> "session_get" API.
>> What they do exactly is left to the PMD implementation. From the 
>> user's perspective, it does not matter.
>> There is no requirement that set pkt metadata will set the udata64 
>> member.
> May be I misunderstood the terminology. "udata64" in mbuf was 
> documented as
> |RTE_STD_C11 union { void *userdata; /**< Can be used for external 
> metadata */ uint64_t udata64; /**< Allow 8-byte userdata on 32-bit */ };|
>
> I thought the metadata in set_pkt_metadata was coming from this. And 
> we were setting this member itself in ixgbe driver.
We're using it in the ixgbe because it is the most obvious choice when 
there is only a small data set to be passed (an table index in this 
case) but it was intended to allow the driver to implement any behavior 
necessary.

>
> But yes, it makes sense not to expose it that way. The API can take 
> mbuf pointer and then, the PMD could dictate how it had set the 
> metadata in rx path.
>
>>>
>>> Thanks,
>>> Anoob
>>>
>>> On 11/20/2017 05:42 PM, Radu Nicolau wrote:
>>>> Hi,
>>>>
>>>>
>>>> Why not have something similar to rte_security_set_pkt_metadata, 
>>>> for example:
>>>>
>>>> void *
>>>> rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>                   struct rte_mbuf *mb);
>>>>
>>>> and keep internally in the PMD all the required references. The 
>>>> returned value will be device-specific, so it's flexible enough to 
>>>> include anything required (just as void *params is in the 
>>>> set_pkt_metadata).
>>>>
>>>> I think it will make a cleaner and more consistent implementation.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Radu
>>>>
>>>>
>>>>
>>>> On 11/20/2017 10:31 AM, Anoob Joseph wrote:
>>>>> In case of inline protocol processed ingress traffic, the packet 
>>>>> may not
>>>>> have enough information to determine the security parameters with 
>>>>> which
>>>>> the packet was processed. In such cases, the application could 
>>>>> register
>>>>> a cookie, which will be saved in the the security session.
>>>>>
>>>>> As the ingress packets are received in the application, it will have
>>>>> some metadata set in the mbuf. Application can pass this metadata to
>>>>> "rte_security_session_get" API to retrieve the security session. Once
>>>>> the security session is determined, another driver call with the
>>>>> security session will give the application the cookie it had 
>>>>> registered.
>>>>>
>>>>> The cookie will be registered while creating the security session.
>>>>> Without the cookie, the selector check (SP-SA check) for the incoming
>>>>> IPsec traffic won't be possible in the application.
>>>>>
>>>>> Application can choose what it should register as the cookie. It can
>>>>> register SPI or a pointer to SA.
>>>>>
>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>> ---
>>>>>   lib/librte_security/rte_security.c        | 26 
>>>>> +++++++++++++++++++++++
>>>>>   lib/librte_security/rte_security.h        | 30 
>>>>> +++++++++++++++++++++++++++
>>>>>   lib/librte_security/rte_security_driver.h | 34 
>>>>> +++++++++++++++++++++++++++++++
>>>>>   3 files changed, 90 insertions(+)
>>>>> <snip>
>>>
>>
> I'll rework the patch to include your suggestions. I'll send a v2 
> after doing this.
>
> Thanks for the feedback,
> Anoob
>

[dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add support for inline protocol

[Anoob Joseph]

Adding support for inline protocol processing.

In ingress side, application will receive regular IP packets, without
any IPsec related info. Application will do a selector check (SP-SA
check) by making use of the cookie it registers while creating the
security session.

In egress side, the plain packet would be submitted to the driver. The
packet will have optional metadata, which could be used to identify the
security session associated with the packet.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
 examples/ipsec-secgw/esp.c         |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c |  40 +++++++++++-
 examples/ipsec-secgw/ipsec.c       | 123 +++++++++++++++++++++++++++++++------
 3 files changed, 147 insertions(+), 22 deletions(-)

diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index c3efe52..561f873 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
 	RTE_ASSERT(sa != NULL);
 	RTE_ASSERT(cop != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
 			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
 				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
@@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
 	RTE_ASSERT(m != NULL);
 	RTE_ASSERT(sa != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
 	} else {
 		RTE_ASSERT(cop != NULL);
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index cfcb9d5..801beda 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -265,6 +265,38 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
 		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
 		rte_pktmbuf_free(pkt);
 	}
+
+	/* Check if the packet has been processed inline. For inline protocol
+	 * processed packets, mbuf would have some metadata which can be
+	 * used to determine the security session. The SA used to create the
+	 * security session will be determined and will be saved in the mbuf.
+	 * This is required for performing the IPsec SP-SA selector check.
+	 */
+
+	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
+		uint64_t cookie;
+		struct rte_security_session *sess;
+		struct ipsec_sa *in_sa;
+		struct ipsec_mbuf_metadata *priv;
+		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
+						rte_eth_dev_get_sec_ctx(
+						pkt->port);
+		if (pkt->udata64 == 0) {
+			/* Metadata not set */
+			return;
+		}
+
+		/* Get the security session from the metadata */
+		sess = rte_security_session_get(ctx, pkt->udata64);
+
+		/* Get the cookie registered by the application */
+		cookie = rte_security_cookie_get(ctx, sess);
+
+		in_sa = (struct ipsec_sa *)cookie;
+
+		priv = get_priv(pkt);
+		priv->sa = in_sa;
+	}
 }
 
 static inline void
@@ -401,11 +433,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
 			ip->pkts[j++] = m;
 			continue;
 		}
-		if (res & DISCARD || i < lim) {
+		if (res & DISCARD) {
 			rte_pktmbuf_free(m);
 			continue;
 		}
+
 		/* Only check SPI match for processed IPSec packets */
+		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
+			rte_pktmbuf_free(m);
+			continue;
+		}
+
 		sa_idx = ip->res[i] & PROTECT_MASK;
 		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
 			rte_pktmbuf_free(m);
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index c24284d..d8e7994 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -46,6 +46,27 @@
 #include "ipsec.h"
 #include "esp.h"
 
+static inline void
+set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
+{
+	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
+		struct rte_security_ipsec_tunnel_param *tunnel =
+				&ipsec->tunnel;
+		if (sa->flags == IP4_TUNNEL) {
+			tunnel->type =
+				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
+			tunnel->ipv4.ttl = IPDEFTTL;
+
+			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
+				(uint8_t *)&sa->src.ip.ip4, 4);
+
+			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
+				(uint8_t *)&sa->dst.ip.ip4, 4);
+		}
+		/* TODO support for Transport and IPV6 tunnel */
+	}
+}
+
 static inline int
 create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 {
@@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
 					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
 			},
-			.crypto_xform = sa->xforms
+			.crypto_xform = sa->xforms,
+			.cookie = 0,
 
 		};
 
@@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 							rte_cryptodev_get_sec_ctx(
 							ipsec_ctx->tbl[cdev_id_qp].id);
 
-			if (sess_conf.ipsec.mode ==
-					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
-				struct rte_security_ipsec_tunnel_param *tunnel =
-						&sess_conf.ipsec.tunnel;
-				if (sa->flags == IP4_TUNNEL) {
-					tunnel->type =
-						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
-					tunnel->ipv4.ttl = IPDEFTTL;
-
-					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
-						(uint8_t *)&sa->src.ip.ip4, 4);
-
-					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
-						(uint8_t *)&sa->dst.ip.ip4, 4);
-				}
-				/* TODO support for Transport and IPV6 tunnel */
-			}
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
 
 			sa->sec_session = rte_security_session_create(ctx,
 					&sess_conf, ipsec_ctx->session_pool);
@@ -206,6 +213,72 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					err.message);
 				return -1;
 			}
+		} else if (sa->type ==
+				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
+			struct rte_security_ctx *ctx =
+					(struct rte_security_ctx *)
+					rte_eth_dev_get_sec_ctx(sa->portid);
+			const struct rte_security_capability *sec_cap;
+
+			if (ctx == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"Ethernet device doesn't have security features registered\n");
+				return -1;
+			}
+
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
+
+			/* Save SA as cookie for the security session. When the
+			 * packet is received, this cookie could be retrieved
+			 * using the metadata set in the packet. If the cookie
+			 * is not set, the application will not be able to
+			 * determine the security parameters with which the
+			 * packet was processed. This is required only for
+			 * inbound SAs.
+			 */
+
+			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
+				sess_conf.cookie = (uint64_t) sa;
+
+			sa->sec_session = rte_security_session_create(ctx,
+					&sess_conf, ipsec_ctx->session_pool);
+			if (sa->sec_session == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"SEC Session init failed: err: %d\n", ret);
+				return -1;
+			}
+
+			sec_cap = rte_security_capabilities_get(ctx);
+
+			if (sec_cap == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"No capabilities registered\n");
+				return -1;
+			}
+
+			/* iterate until ESP tunnel*/
+			while (sec_cap->action !=
+					RTE_SECURITY_ACTION_TYPE_NONE) {
+
+				if (sec_cap->action == sa->type &&
+				    sec_cap->protocol ==
+					RTE_SECURITY_PROTOCOL_IPSEC &&
+				    sec_cap->ipsec.mode ==
+					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
+				    sec_cap->ipsec.direction == sa->direction)
+					break;
+				sec_cap++;
+			}
+
+			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
+				RTE_LOG(ERR, IPSEC,
+				"No suitable security capability found\n");
+				return -1;
+			}
+
+			sa->ol_flags = sec_cap->ol_flags;
+			sa->security_ctx = ctx;
 		}
 	} else {
 		sa->crypto_session = rte_cryptodev_sym_session_create(
@@ -323,7 +396,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
 			}
 			break;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-			break;
+			if ((unlikely(sa->sec_session == NULL)) &&
+					create_session(ipsec_ctx, sa)) {
+				rte_pktmbuf_free(pkts[i]);
+				continue;
+			}
+
+			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
+			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
+			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
+				rte_security_set_pkt_metadata(
+						sa->security_ctx,
+						sa->sec_session, pkts[i], NULL);
+			continue;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
 			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
 			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
-- 
2.7.4

[dpdk-dev] [PATCH v2 0/2] add inline protocol support

[Anoob Joseph]

The series adds inline protocol support in ipsec-secgw application.

First patch introduces changes in lib to enable applications to save a
64 bit metadata in security session. For inline processed packets,
application could call "rte_security_get_pkt_metadata" API to retrieve
this application registered metadata from the packet. API will return
the metadata associated with the security session which processed the
packet.

This is primarily required for inline protocol processed ingress
packets. For such packets, the packet may not have enough information to
identify the security parameters with which the packet was processed.
Application can register what it needs to identify the required
parameter. The metadata will be set while creating the security
session.

Second patch adds support for inline protocol in ipsec-secgw
application.

Anoob Joseph (2):
  lib/security: add support for get metadata
  examples/ipsec-secgw: add support for inline protocol

 examples/ipsec-secgw/esp.c                |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c        |  41 +++++++++-
 examples/ipsec-secgw/ipsec.c              | 121 +++++++++++++++++++++++++-----
 lib/librte_security/rte_security.c        |  13 ++++
 lib/librte_security/rte_security.h        |  19 +++++
 lib/librte_security/rte_security_driver.h |  16 ++++
 6 files changed, 194 insertions(+), 22 deletions(-)

-- 
v2: Replaced get_session and get_cookie APIs with get_pkt_metadata API

2.7.4

[dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata

[Anoob Joseph]

In case of inline protocol processed ingress traffic, the packet may not
have enough information to determine the security parameters with which
the packet was processed. For such cases, application could register a
64 bit metadata in security session, which could be retrieved from the
packet using "rte_security_get_pkt_metadata" API. Application can use
this metadata to identify the parameters it need.

Application can choose what it should register as the metadata. It can
register SPI or a pointer to SA.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* Replaced get_session and get_cookie APIs with get_pkt_metadata API

 lib/librte_security/rte_security.c        | 13 +++++++++++++
 lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
 lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
 3 files changed, 48 insertions(+)

diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
index 1227fca..804f11f 100644
--- a/lib/librte_security/rte_security.c
+++ b/lib/librte_security/rte_security.c
@@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 					       sess, m, params);
 }
 
+uint64_t
+rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
+			      struct rte_mbuf *pkt)
+{
+	uint64_t mdata = 0;
+
+	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 0);
+	if (instance->ops->get_pkt_metadata(instance->device, pkt, &mdata))
+		return 0;
+
+	return mdata;
+}
+
 const struct rte_security_capability *
 rte_security_capabilities_get(struct rte_security_ctx *instance)
 {
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index 653929b..aa3a471 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -274,6 +274,8 @@ struct rte_security_session_conf {
 	/**< Configuration parameters for security session */
 	struct rte_crypto_sym_xform *crypto_xform;
 	/**< Security Session Crypto Transformations */
+	uint64_t metadata;
+	/**< Metadata registered by application */
 };
 
 struct rte_security_session {
@@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 			      struct rte_mbuf *mb, void *params);
 
 /**
+ * Get metadata from the packet. This is an application registered 64 bit
+ * value, associated with the security session which processed the packet.
+ *
+ * This is valid only for inline processed ingress packets.
+ *
+ * @param   instance	security instance
+ * @param   pkt		packet mbuf
+ *
+ * @return
+ *  - On success, metadata
+ *  - On failure, 0
+ */
+uint64_t
+rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
+			      struct rte_mbuf *pkt);
+
+/**
  * Attach a session to a symmetric crypto operation
  *
  * @param	sym_op	crypto operation
diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
index 997fbe7..da0ebf4 100644
--- a/lib/librte_security/rte_security_driver.h
+++ b/lib/librte_security/rte_security_driver.h
@@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
 		void *params);
 
 /**
+ * Get application interpretable metadata from the packet.
+ *
+ * @param	device		Crypto/eth device pointer
+ * @param	pkt		Packet mbuf
+ * @param	mt		Pointer to receive metadata
+ *
+ * @return
+ *  - Returns 0 if metadata is retrieved successfully.
+ *  - Returns -ve value for errors.
+ */
+typedef int (*security_get_pkt_metadata_t)(void *device,
+		struct rte_mbuf *pkt, uint64_t *mt);
+
+/**
  * Get security capabilities of the device.
  *
  * @param	device		crypto/eth device pointer
@@ -145,6 +159,8 @@ struct rte_security_ops {
 	/**< Clear a security sessions private data. */
 	security_set_pkt_metadata_t set_pkt_metadata;
 	/**< Update mbuf metadata. */
+	security_get_pkt_metadata_t get_pkt_metadata;
+	/**< Get metadata from packet. */
 	security_capabilities_get_t capabilities_get;
 	/**< Get security capabilities. */
 };
-- 
2.7.4

Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata

[Radu Nicolau]

On 11/22/2017 6:55 AM, Anoob Joseph wrote:
> In case of inline protocol processed ingress traffic, the packet may not
> have enough information to determine the security parameters with which
> the packet was processed. For such cases, application could register a
> 64 bit metadata in security session, which could be retrieved from the
> packet using "rte_security_get_pkt_metadata" API. Application can use
> this metadata to identify the parameters it need.
>
> Application can choose what it should register as the metadata. It can
> register SPI or a pointer to SA.
>
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
> v2:
> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>
>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>   3 files changed, 48 insertions(+)
>
> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> index 1227fca..804f11f 100644
> --- a/lib/librte_security/rte_security.c
> +++ b/lib/librte_security/rte_security.c
> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>   					       sess, m, params);
>   }
>   
> +uint64_t
> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
> +			      struct rte_mbuf *pkt)
> +{
> +	uint64_t mdata = 0;
> +
> +	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 0);
> +	if (instance->ops->get_pkt_metadata(instance->device, pkt, &mdata))
> +		return 0;
> +
> +	return mdata;
> +}
> +
Can you change the returned type to void *?
>   const struct rte_security_capability *
>   rte_security_capabilities_get(struct rte_security_ctx *instance)
>   {
> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> index 653929b..aa3a471 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -274,6 +274,8 @@ struct rte_security_session_conf {
>   	/**< Configuration parameters for security session */
>   	struct rte_crypto_sym_xform *crypto_xform;
>   	/**< Security Session Crypto Transformations */
> +	uint64_t metadata;
> +	/**< Metadata registered by application */
>   };
Can you rename it to userdata?
>   
>   struct rte_security_session {
> @@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>   			      struct rte_mbuf *mb, void *params);
>   
>   /**
> + * Get metadata from the packet. This is an application registered 64 bit
> + * value, associated with the security session which processed the packet.
> + *
> + * This is valid only for inline processed ingress packets.
> + *
> + * @param   instance	security instance
> + * @param   pkt		packet mbuf
> + *
> + * @return
> + *  - On success, metadata
> + *  - On failure, 0
> + */
> +uint64_t
> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
> +			      struct rte_mbuf *pkt);
> +
> +/**
>    * Attach a session to a symmetric crypto operation
>    *
>    * @param	sym_op	crypto operation
> diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
> index 997fbe7..da0ebf4 100644
> --- a/lib/librte_security/rte_security_driver.h
> +++ b/lib/librte_security/rte_security_driver.h
> @@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
>   		void *params);
>   
>   /**
> + * Get application interpretable metadata from the packet.
> + *
> + * @param	device		Crypto/eth device pointer
> + * @param	pkt		Packet mbuf
> + * @param	mt		Pointer to receive metadata
> + *
> + * @return
> + *  - Returns 0 if metadata is retrieved successfully.
> + *  - Returns -ve value for errors.
> + */
> +typedef int (*security_get_pkt_metadata_t)(void *device,
> +		struct rte_mbuf *pkt, uint64_t *mt);
> +
> +/**
>    * Get security capabilities of the device.
>    *
>    * @param	device		crypto/eth device pointer
> @@ -145,6 +159,8 @@ struct rte_security_ops {
>   	/**< Clear a security sessions private data. */
>   	security_set_pkt_metadata_t set_pkt_metadata;
>   	/**< Update mbuf metadata. */
> +	security_get_pkt_metadata_t get_pkt_metadata;
> +	/**< Get metadata from packet. */
>   	security_capabilities_get_t capabilities_get;
>   	/**< Get security capabilities. */
>   };

Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata

[Anoob]

Hi,

See inline.


Thanks,
Anoob

On 11/22/2017 04:59 PM, Radu Nicolau wrote:
>
>
> On 11/22/2017 6:55 AM, Anoob Joseph wrote:
>> In case of inline protocol processed ingress traffic, the packet may not
>> have enough information to determine the security parameters with which
>> the packet was processed. For such cases, application could register a
>> 64 bit metadata in security session, which could be retrieved from the
>> packet using "rte_security_get_pkt_metadata" API. Application can use
>> this metadata to identify the parameters it need.
>>
>> Application can choose what it should register as the metadata. It can
>> register SPI or a pointer to SA.
>>
>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> ---
>> v2:
>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>
>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>   3 files changed, 48 insertions(+)
>>
>> diff --git a/lib/librte_security/rte_security.c 
>> b/lib/librte_security/rte_security.c
>> index 1227fca..804f11f 100644
>> --- a/lib/librte_security/rte_security.c
>> +++ b/lib/librte_security/rte_security.c
>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>> rte_security_ctx *instance,
>>                              sess, m, params);
>>   }
>>   +uint64_t
>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>> +                  struct rte_mbuf *pkt)
>> +{
>> +    uint64_t mdata = 0;
>> +
>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 0);
>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, &mdata))
>> +        return 0;
>> +
>> +    return mdata;
>> +}
>> +
> Can you change the returned type to void *?
Will do that.
>>   const struct rte_security_capability *
>>   rte_security_capabilities_get(struct rte_security_ctx *instance)
>>   {
>> diff --git a/lib/librte_security/rte_security.h 
>> b/lib/librte_security/rte_security.h
>> index 653929b..aa3a471 100644
>> --- a/lib/librte_security/rte_security.h
>> +++ b/lib/librte_security/rte_security.h
>> @@ -274,6 +274,8 @@ struct rte_security_session_conf {
>>       /**< Configuration parameters for security session */
>>       struct rte_crypto_sym_xform *crypto_xform;
>>       /**< Security Session Crypto Transformations */
>> +    uint64_t metadata;
>> +    /**< Metadata registered by application */
>>   };
> Can you rename it to userdata?
Will do it. Thought it would be confusing, as this will be returned by 
rte_security_get_pkt_metadata. So get_metadata would give userdata of 
the security session. I can document it that way and proceed, right?
>>     struct rte_security_session {
>> @@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct 
>> rte_security_ctx *instance,
>>                     struct rte_mbuf *mb, void *params);
>>     /**
>> + * Get metadata from the packet. This is an application registered 
>> 64 bit
>> + * value, associated with the security session which processed the 
>> packet.
>> + *
>> + * This is valid only for inline processed ingress packets.
>> + *
>> + * @param   instance    security instance
>> + * @param   pkt        packet mbuf
>> + *
>> + * @return
>> + *  - On success, metadata
>> + *  - On failure, 0
>> + */
>> +uint64_t
>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>> +                  struct rte_mbuf *pkt);
>> +
>> +/**
>>    * Attach a session to a symmetric crypto operation
>>    *
>>    * @param    sym_op    crypto operation
>> diff --git a/lib/librte_security/rte_security_driver.h 
>> b/lib/librte_security/rte_security_driver.h
>> index 997fbe7..da0ebf4 100644
>> --- a/lib/librte_security/rte_security_driver.h
>> +++ b/lib/librte_security/rte_security_driver.h
>> @@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void 
>> *device,
>>           void *params);
>>     /**
>> + * Get application interpretable metadata from the packet.
>> + *
>> + * @param    device        Crypto/eth device pointer
>> + * @param    pkt        Packet mbuf
>> + * @param    mt        Pointer to receive metadata
>> + *
>> + * @return
>> + *  - Returns 0 if metadata is retrieved successfully.
>> + *  - Returns -ve value for errors.
>> + */
>> +typedef int (*security_get_pkt_metadata_t)(void *device,
>> +        struct rte_mbuf *pkt, uint64_t *mt);
>> +
>> +/**
>>    * Get security capabilities of the device.
>>    *
>>    * @param    device        crypto/eth device pointer
>> @@ -145,6 +159,8 @@ struct rte_security_ops {
>>       /**< Clear a security sessions private data. */
>>       security_set_pkt_metadata_t set_pkt_metadata;
>>       /**< Update mbuf metadata. */
>> +    security_get_pkt_metadata_t get_pkt_metadata;
>> +    /**< Get metadata from packet. */
>>       security_capabilities_get_t capabilities_get;
>>       /**< Get security capabilities. */
>>   };
>

Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata

[Radu Nicolau]

On 11/22/2017 11:52 AM, Anoob wrote:
> Hi,
>
> See inline.
>
>
> Thanks,
> Anoob
>
> On 11/22/2017 04:59 PM, Radu Nicolau wrote:
>>
>>
>> On 11/22/2017 6:55 AM, Anoob Joseph wrote:
>>> In case of inline protocol processed ingress traffic, the packet may 
>>> not
>>> have enough information to determine the security parameters with which
>>> the packet was processed. For such cases, application could register a
>>> 64 bit metadata in security session, which could be retrieved from the
>>> packet using "rte_security_get_pkt_metadata" API. Application can use
>>> this metadata to identify the parameters it need.
>>>
>>> Application can choose what it should register as the metadata. It can
>>> register SPI or a pointer to SA.
>>>
>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>> ---
>>> v2:
>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>>
>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>   3 files changed, 48 insertions(+)
>>>
>>> diff --git a/lib/librte_security/rte_security.c 
>>> b/lib/librte_security/rte_security.c
>>> index 1227fca..804f11f 100644
>>> --- a/lib/librte_security/rte_security.c
>>> +++ b/lib/librte_security/rte_security.c
>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>> rte_security_ctx *instance,
>>>                              sess, m, params);
>>>   }
>>>   +uint64_t
>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>> +                  struct rte_mbuf *pkt)
>>> +{
>>> +    uint64_t mdata = 0;
>>> +
>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 0);
>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, 
>>> &mdata))
>>> +        return 0;
>>> +
>>> +    return mdata;
>>> +}
>>> +
>> Can you change the returned type to void *?
> Will do that.
>>>   const struct rte_security_capability *
>>>   rte_security_capabilities_get(struct rte_security_ctx *instance)
>>>   {
>>> diff --git a/lib/librte_security/rte_security.h 
>>> b/lib/librte_security/rte_security.h
>>> index 653929b..aa3a471 100644
>>> --- a/lib/librte_security/rte_security.h
>>> +++ b/lib/librte_security/rte_security.h
>>> @@ -274,6 +274,8 @@ struct rte_security_session_conf {
>>>       /**< Configuration parameters for security session */
>>>       struct rte_crypto_sym_xform *crypto_xform;
>>>       /**< Security Session Crypto Transformations */
>>> +    uint64_t metadata;
>>> +    /**< Metadata registered by application */
>>>   };
>> Can you rename it to userdata?
> Will do it. Thought it would be confusing, as this will be returned by 
> rte_security_get_pkt_metadata. So get_metadata would give userdata of 
> the security session. I can document it that way and proceed, right?
Also make it a pointer please.
You should document it in the PMD documentation, as this is a PMD 
specific behavior. Your PMD returns just the userdata pointer set in the 
security_conf struct, but other PMDs can return different things.
>>>     struct rte_security_session {
>>> @@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct 
>>> rte_security_ctx *instance,
>>>                     struct rte_mbuf *mb, void *params);
>>>     /**
>>> + * Get metadata from the packet. This is an application registered 
>>> 64 bit
>>> + * value, associated with the security session which processed the 
>>> packet.
>>> + *
>>> + * This is valid only for inline processed ingress packets.
>>> + *
>>> + * @param   instance    security instance
>>> + * @param   pkt        packet mbuf
>>> + *
>>> + * @return
>>> + *  - On success, metadata
>>> + *  - On failure, 0
>>> + */
>>> +uint64_t
>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>> +                  struct rte_mbuf *pkt);
>>> +
>>> +/**
>>>    * Attach a session to a symmetric crypto operation
>>>    *
>>>    * @param    sym_op    crypto operation
>>> diff --git a/lib/librte_security/rte_security_driver.h 
>>> b/lib/librte_security/rte_security_driver.h
>>> index 997fbe7..da0ebf4 100644
>>> --- a/lib/librte_security/rte_security_driver.h
>>> +++ b/lib/librte_security/rte_security_driver.h
>>> @@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void 
>>> *device,
>>>           void *params);
>>>     /**
>>> + * Get application interpretable metadata from the packet.
>>> + *
>>> + * @param    device        Crypto/eth device pointer
>>> + * @param    pkt        Packet mbuf
>>> + * @param    mt        Pointer to receive metadata
>>> + *
>>> + * @return
>>> + *  - Returns 0 if metadata is retrieved successfully.
>>> + *  - Returns -ve value for errors.
>>> + */
>>> +typedef int (*security_get_pkt_metadata_t)(void *device,
>>> +        struct rte_mbuf *pkt, uint64_t *mt);
>>> +
>>> +/**
>>>    * Get security capabilities of the device.
>>>    *
>>>    * @param    device        crypto/eth device pointer
>>> @@ -145,6 +159,8 @@ struct rte_security_ops {
>>>       /**< Clear a security sessions private data. */
>>>       security_set_pkt_metadata_t set_pkt_metadata;
>>>       /**< Update mbuf metadata. */
>>> +    security_get_pkt_metadata_t get_pkt_metadata;
>>> +    /**< Get metadata from packet. */
>>>       security_capabilities_get_t capabilities_get;
>>>       /**< Get security capabilities. */
>>>   };
>>
>

Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata

[Neil Horman]

On Wed, Nov 22, 2017 at 06:55:15AM +0000, Anoob Joseph wrote:
> In case of inline protocol processed ingress traffic, the packet may not
> have enough information to determine the security parameters with which
> the packet was processed. For such cases, application could register a
> 64 bit metadata in security session, which could be retrieved from the
> packet using "rte_security_get_pkt_metadata" API. Application can use
> this metadata to identify the parameters it need.
> 
> Application can choose what it should register as the metadata. It can
> register SPI or a pointer to SA.
> 
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
> v2:
> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
> 
>  lib/librte_security/rte_security.c        | 13 +++++++++++++
>  lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>  lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>  3 files changed, 48 insertions(+)
> 
> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> index 1227fca..804f11f 100644
> --- a/lib/librte_security/rte_security.c
> +++ b/lib/librte_security/rte_security.c
> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>  					       sess, m, params);
>  }
>  
> +uint64_t
> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
> +			      struct rte_mbuf *pkt)
> +{
> +	uint64_t mdata = 0;
> +
> +	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 0);
> +	if (instance->ops->get_pkt_metadata(instance->device, pkt, &mdata))
> +		return 0;
> +
> +	return mdata;
> +}
> +
>  const struct rte_security_capability *
>  rte_security_capabilities_get(struct rte_security_ctx *instance)
>  {
> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> index 653929b..aa3a471 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -274,6 +274,8 @@ struct rte_security_session_conf {
>  	/**< Configuration parameters for security session */
>  	struct rte_crypto_sym_xform *crypto_xform;
>  	/**< Security Session Crypto Transformations */
> +	uint64_t metadata;
> +	/**< Metadata registered by application */
This is going to break ABI. You need to announce the change so that application
providers can be prepared for it.

>  };
>  
>  struct rte_security_session {
> @@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>  			      struct rte_mbuf *mb, void *params);
>  
>  /**
> + * Get metadata from the packet. This is an application registered 64 bit
> + * value, associated with the security session which processed the packet.
> + *
> + * This is valid only for inline processed ingress packets.
> + *
> + * @param   instance	security instance
> + * @param   pkt		packet mbuf
> + *
> + * @return
> + *  - On success, metadata
> + *  - On failure, 0
> + */
> +uint64_t
> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
> +			      struct rte_mbuf *pkt);
> +
> +/**
>   * Attach a session to a symmetric crypto operation
>   *
>   * @param	sym_op	crypto operation
> diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
> index 997fbe7..da0ebf4 100644
> --- a/lib/librte_security/rte_security_driver.h
> +++ b/lib/librte_security/rte_security_driver.h
> @@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
>  		void *params);
>  
>  /**
> + * Get application interpretable metadata from the packet.
> + *
> + * @param	device		Crypto/eth device pointer
> + * @param	pkt		Packet mbuf
> + * @param	mt		Pointer to receive metadata
> + *
> + * @return
> + *  - Returns 0 if metadata is retrieved successfully.
> + *  - Returns -ve value for errors.
> + */
> +typedef int (*security_get_pkt_metadata_t)(void *device,
> +		struct rte_mbuf *pkt, uint64_t *mt);
> +
> +/**
>   * Get security capabilities of the device.
>   *
>   * @param	device		crypto/eth device pointer
> @@ -145,6 +159,8 @@ struct rte_security_ops {
>  	/**< Clear a security sessions private data. */
>  	security_set_pkt_metadata_t set_pkt_metadata;
>  	/**< Update mbuf metadata. */
> +	security_get_pkt_metadata_t get_pkt_metadata;
> +	/**< Get metadata from packet. */
>  	security_capabilities_get_t capabilities_get;
>  	/**< Get security capabilities. */
>  };
> -- 
> 2.7.4
> 
> 

Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata

[Anoob]

Hi,

Please see inline.


On 11/22/2017 06:57 PM, Neil Horman wrote:
> On Wed, Nov 22, 2017 at 06:55:15AM +0000, Anoob Joseph wrote:
>> In case of inline protocol processed ingress traffic, the packet may not
>> have enough information to determine the security parameters with which
>> the packet was processed. For such cases, application could register a
>> 64 bit metadata in security session, which could be retrieved from the
>> packet using "rte_security_get_pkt_metadata" API. Application can use
>> this metadata to identify the parameters it need.
>>
>> Application can choose what it should register as the metadata. It can
>> register SPI or a pointer to SA.
>>
>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> ---
>> v2:
>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>
>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>   3 files changed, 48 insertions(+)
>>
>> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
>> index 1227fca..804f11f 100644
>> --- a/lib/librte_security/rte_security.c
>> +++ b/lib/librte_security/rte_security.c
>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>>   					       sess, m, params);
>>   }
>>   
>> +uint64_t
>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>> +			      struct rte_mbuf *pkt)
>> +{
>> +	uint64_t mdata = 0;
>> +
>> +	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 0);
>> +	if (instance->ops->get_pkt_metadata(instance->device, pkt, &mdata))
>> +		return 0;
>> +
>> +	return mdata;
>> +}
>> +
>>   const struct rte_security_capability *
>>   rte_security_capabilities_get(struct rte_security_ctx *instance)
>>   {
>> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
>> index 653929b..aa3a471 100644
>> --- a/lib/librte_security/rte_security.h
>> +++ b/lib/librte_security/rte_security.h
>> @@ -274,6 +274,8 @@ struct rte_security_session_conf {
>>   	/**< Configuration parameters for security session */
>>   	struct rte_crypto_sym_xform *crypto_xform;
>>   	/**< Security Session Crypto Transformations */
>> +	uint64_t metadata;
>> +	/**< Metadata registered by application */
> This is going to break ABI. You need to announce the change so that application
> providers can be prepared for it.
The security library is under experimental tag. So is the announcement 
required?
>
>>   };
>>   
>>   struct rte_security_session {
>> @@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>>   			      struct rte_mbuf *mb, void *params);
>>   
>>   /**
>> + * Get metadata from the packet. This is an application registered 64 bit
>> + * value, associated with the security session which processed the packet.
>> + *
>> + * This is valid only for inline processed ingress packets.
>> + *
>> + * @param   instance	security instance
>> + * @param   pkt		packet mbuf
>> + *
>> + * @return
>> + *  - On success, metadata
>> + *  - On failure, 0
>> + */
>> +uint64_t
>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>> +			      struct rte_mbuf *pkt);
>> +
>> +/**
>>    * Attach a session to a symmetric crypto operation
>>    *
>>    * @param	sym_op	crypto operation
>> diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
>> index 997fbe7..da0ebf4 100644
>> --- a/lib/librte_security/rte_security_driver.h
>> +++ b/lib/librte_security/rte_security_driver.h
>> @@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
>>   		void *params);
>>   
>>   /**
>> + * Get application interpretable metadata from the packet.
>> + *
>> + * @param	device		Crypto/eth device pointer
>> + * @param	pkt		Packet mbuf
>> + * @param	mt		Pointer to receive metadata
>> + *
>> + * @return
>> + *  - Returns 0 if metadata is retrieved successfully.
>> + *  - Returns -ve value for errors.
>> + */
>> +typedef int (*security_get_pkt_metadata_t)(void *device,
>> +		struct rte_mbuf *pkt, uint64_t *mt);
>> +
>> +/**
>>    * Get security capabilities of the device.
>>    *
>>    * @param	device		crypto/eth device pointer
>> @@ -145,6 +159,8 @@ struct rte_security_ops {
>>   	/**< Clear a security sessions private data. */
>>   	security_set_pkt_metadata_t set_pkt_metadata;
>>   	/**< Update mbuf metadata. */
>> +	security_get_pkt_metadata_t get_pkt_metadata;
>> +	/**< Get metadata from packet. */
>>   	security_capabilities_get_t capabilities_get;
>>   	/**< Get security capabilities. */
>>   };
>> -- 
>> 2.7.4
>>
>>

Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata

[Neil Horman]

On Wed, Nov 22, 2017 at 07:43:13PM +0530, Anoob wrote:
> Hi,
> 
> Please see inline.
> 
> 
> On 11/22/2017 06:57 PM, Neil Horman wrote:
> > On Wed, Nov 22, 2017 at 06:55:15AM +0000, Anoob Joseph wrote:
> > > In case of inline protocol processed ingress traffic, the packet may not
> > > have enough information to determine the security parameters with which
> > > the packet was processed. For such cases, application could register a
> > > 64 bit metadata in security session, which could be retrieved from the
> > > packet using "rte_security_get_pkt_metadata" API. Application can use
> > > this metadata to identify the parameters it need.
> > > 
> > > Application can choose what it should register as the metadata. It can
> > > register SPI or a pointer to SA.
> > > 
> > > Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> > > ---
> > > v2:
> > > * Replaced get_session and get_cookie APIs with get_pkt_metadata API
> > > 
> > >   lib/librte_security/rte_security.c        | 13 +++++++++++++
> > >   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
> > >   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
> > >   3 files changed, 48 insertions(+)
> > > 
> > > diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> > > index 1227fca..804f11f 100644
> > > --- a/lib/librte_security/rte_security.c
> > > +++ b/lib/librte_security/rte_security.c
> > > @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
> > >   					       sess, m, params);
> > >   }
> > > +uint64_t
> > > +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
> > > +			      struct rte_mbuf *pkt)
> > > +{
> > > +	uint64_t mdata = 0;
> > > +
> > > +	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 0);
> > > +	if (instance->ops->get_pkt_metadata(instance->device, pkt, &mdata))
> > > +		return 0;
> > > +
> > > +	return mdata;
> > > +}
> > > +
> > >   const struct rte_security_capability *
> > >   rte_security_capabilities_get(struct rte_security_ctx *instance)
> > >   {
> > > diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> > > index 653929b..aa3a471 100644
> > > --- a/lib/librte_security/rte_security.h
> > > +++ b/lib/librte_security/rte_security.h
> > > @@ -274,6 +274,8 @@ struct rte_security_session_conf {
> > >   	/**< Configuration parameters for security session */
> > >   	struct rte_crypto_sym_xform *crypto_xform;
> > >   	/**< Security Session Crypto Transformations */
> > > +	uint64_t metadata;
> > > +	/**< Metadata registered by application */
> > This is going to break ABI. You need to announce the change so that application
> > providers can be prepared for it.
> The security library is under experimental tag. So is the announcement
> required?
Ah, thats correct, its not required.  That said, thats probably the fourth time
I've reviewed a patch and tripped over the fact that it was experimental.  We
should probably look at ways at making that fact more visible at review, compile
and run time

Neil

> > 
> > >   };
> > >   struct rte_security_session {
> > > @@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
> > >   			      struct rte_mbuf *mb, void *params);
> > >   /**
> > > + * Get metadata from the packet. This is an application registered 64 bit
> > > + * value, associated with the security session which processed the packet.
> > > + *
> > > + * This is valid only for inline processed ingress packets.
> > > + *
> > > + * @param   instance	security instance
> > > + * @param   pkt		packet mbuf
> > > + *
> > > + * @return
> > > + *  - On success, metadata
> > > + *  - On failure, 0
> > > + */
> > > +uint64_t
> > > +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
> > > +			      struct rte_mbuf *pkt);
> > > +
> > > +/**
> > >    * Attach a session to a symmetric crypto operation
> > >    *
> > >    * @param	sym_op	crypto operation
> > > diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
> > > index 997fbe7..da0ebf4 100644
> > > --- a/lib/librte_security/rte_security_driver.h
> > > +++ b/lib/librte_security/rte_security_driver.h
> > > @@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
> > >   		void *params);
> > >   /**
> > > + * Get application interpretable metadata from the packet.
> > > + *
> > > + * @param	device		Crypto/eth device pointer
> > > + * @param	pkt		Packet mbuf
> > > + * @param	mt		Pointer to receive metadata
> > > + *
> > > + * @return
> > > + *  - Returns 0 if metadata is retrieved successfully.
> > > + *  - Returns -ve value for errors.
> > > + */
> > > +typedef int (*security_get_pkt_metadata_t)(void *device,
> > > +		struct rte_mbuf *pkt, uint64_t *mt);
> > > +
> > > +/**
> > >    * Get security capabilities of the device.
> > >    *
> > >    * @param	device		crypto/eth device pointer
> > > @@ -145,6 +159,8 @@ struct rte_security_ops {
> > >   	/**< Clear a security sessions private data. */
> > >   	security_set_pkt_metadata_t set_pkt_metadata;
> > >   	/**< Update mbuf metadata. */
> > > +	security_get_pkt_metadata_t get_pkt_metadata;
> > > +	/**< Get metadata from packet. */
> > >   	security_capabilities_get_t capabilities_get;
> > >   	/**< Get security capabilities. */
> > >   };
> > > -- 
> > > 2.7.4
> > > 
> > > 
> 
> 

[dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: add support for inline protocol

[Anoob Joseph]

Adding support for inline protocol processing

In ingress side, application will receive regular IP packets, without
any IPsec related info. Application will do a selector check (SP-SA
check) by making use of the metadata from the packet.

In egress side, the plain packet would be submitted to the driver. The
packet will have optional metadata, which could be used to identify the
security session associated with the packet.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v2:
* Using get_pkt_metadata API instead of get_session & get_cookie APIs

 examples/ipsec-secgw/esp.c         |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c |  41 ++++++++++++-
 examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
 3 files changed, 146 insertions(+), 22 deletions(-)

diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index c3efe52..561f873 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
 	RTE_ASSERT(sa != NULL);
 	RTE_ASSERT(cop != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
 			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
 				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
@@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
 	RTE_ASSERT(m != NULL);
 	RTE_ASSERT(sa != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
 	} else {
 		RTE_ASSERT(cop != NULL);
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index c98454a..4578bf5 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -265,6 +265,39 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
 		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
 		rte_pktmbuf_free(pkt);
 	}
+
+	/* Check if the packet has been processed inline. For inline protocol
+	 * processed packets, metadata from the packet need to be obtained.
+	 * This metadata will be registered by application when it is
+	 * created and will be used to determine the SA associated.
+	 */
+
+	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
+		uint64_t mdata;
+		struct ipsec_sa *in_sa;
+		struct ipsec_mbuf_metadata *priv;
+		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
+						rte_eth_dev_get_sec_ctx(
+						pkt->port);
+
+		/* Get the application registered metadata from the packet */
+		mdata = rte_security_get_pkt_metadata(ctx, pkt);
+
+		if (mdata == 0) {
+			/* Metadata could not be retrieved */
+			return;
+		}
+
+		/* The SA was saved as metadata when the session was
+		 * created. Save this as private data in mbuf. This will
+		 * be used in the IPsec selector(SP-SA) check.
+		 */
+
+		in_sa = (struct ipsec_sa *)mdata;
+
+		priv = get_priv(pkt);
+		priv->sa = in_sa;
+	}
 }
 
 static inline void
@@ -401,11 +434,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
 			ip->pkts[j++] = m;
 			continue;
 		}
-		if (res & DISCARD || i < lim) {
+		if (res & DISCARD) {
 			rte_pktmbuf_free(m);
 			continue;
 		}
+
 		/* Only check SPI match for processed IPSec packets */
+		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
+			rte_pktmbuf_free(m);
+			continue;
+		}
+
 		sa_idx = ip->res[i] & PROTECT_MASK;
 		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
 			rte_pktmbuf_free(m);
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 70ed227..ec8bf95 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -46,6 +46,27 @@
 #include "ipsec.h"
 #include "esp.h"
 
+static inline void
+set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
+{
+	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
+		struct rte_security_ipsec_tunnel_param *tunnel =
+				&ipsec->tunnel;
+		if (sa->flags == IP4_TUNNEL) {
+			tunnel->type =
+				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
+			tunnel->ipv4.ttl = IPDEFTTL;
+
+			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
+				(uint8_t *)&sa->src.ip.ip4, 4);
+
+			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
+				(uint8_t *)&sa->dst.ip.ip4, 4);
+		}
+		/* TODO support for Transport and IPV6 tunnel */
+	}
+}
+
 static inline int
 create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 {
@@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
 					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
 			} },
-			.crypto_xform = sa->xforms
+			.crypto_xform = sa->xforms,
+			.metadata = 0,
 
 		};
 
@@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 							rte_cryptodev_get_sec_ctx(
 							ipsec_ctx->tbl[cdev_id_qp].id);
 
-			if (sess_conf.ipsec.mode ==
-					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
-				struct rte_security_ipsec_tunnel_param *tunnel =
-						&sess_conf.ipsec.tunnel;
-				if (sa->flags == IP4_TUNNEL) {
-					tunnel->type =
-						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
-					tunnel->ipv4.ttl = IPDEFTTL;
-
-					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
-						(uint8_t *)&sa->src.ip.ip4, 4);
-
-					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
-						(uint8_t *)&sa->dst.ip.ip4, 4);
-				}
-				/* TODO support for Transport and IPV6 tunnel */
-			}
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
 
 			sa->sec_session = rte_security_session_create(ctx,
 					&sess_conf, ipsec_ctx->session_pool);
@@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					err.message);
 				return -1;
 			}
+		} else if (sa->type ==
+				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
+			struct rte_security_ctx *ctx =
+					(struct rte_security_ctx *)
+					rte_eth_dev_get_sec_ctx(sa->portid);
+			const struct rte_security_capability *sec_cap;
+
+			if (ctx == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"Ethernet device doesn't have security features registered\n");
+				return -1;
+			}
+
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
+
+			/* Save SA as metadata for the security session. When
+			 * the packet is received, this metadata (security
+			 * session metadata) will be retrieved from the packet.
+			 *
+			 * This is required only for inbound SAs.
+			 */
+
+			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
+				sess_conf.metadata = (uint64_t) sa;
+
+			sa->sec_session = rte_security_session_create(ctx,
+					&sess_conf, ipsec_ctx->session_pool);
+			if (sa->sec_session == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"SEC Session init failed: err: %d\n", ret);
+				return -1;
+			}
+
+			sec_cap = rte_security_capabilities_get(ctx);
+
+			if (sec_cap == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"No capabilities registered\n");
+				return -1;
+			}
+
+			/* iterate until ESP tunnel*/
+			while (sec_cap->action !=
+					RTE_SECURITY_ACTION_TYPE_NONE) {
+
+				if (sec_cap->action == sa->type &&
+				    sec_cap->protocol ==
+					RTE_SECURITY_PROTOCOL_IPSEC &&
+				    sec_cap->ipsec.mode ==
+					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
+				    sec_cap->ipsec.direction == sa->direction)
+					break;
+				sec_cap++;
+			}
+
+			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
+				RTE_LOG(ERR, IPSEC,
+				"No suitable security capability found\n");
+				return -1;
+			}
+
+			sa->ol_flags = sec_cap->ol_flags;
+			sa->security_ctx = ctx;
 		}
 	} else {
 		sa->crypto_session = rte_cryptodev_sym_session_create(
@@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
 			}
 			break;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-			break;
+			if ((unlikely(sa->sec_session == NULL)) &&
+					create_session(ipsec_ctx, sa)) {
+				rte_pktmbuf_free(pkts[i]);
+				continue;
+			}
+
+			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
+			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
+			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
+				rte_security_set_pkt_metadata(
+						sa->security_ctx,
+						sa->sec_session, pkts[i], NULL);
+			continue;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
 			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
 			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
-- 
2.7.4

Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support

[Nelio Laranjeiro]

Hi Anoob,

I am facing a segfault in ipsec-secgw with this series when using MLX5
PMD, maybe you can help here, see the following gdb backtrace.

 Thread 1 "ipsec-secgw" received signal SIGSEGV, Segmentation fault.
 0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
 378             sym_op->sec_session = sess;
 (gdb) bt
 #0  0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
 #1  0x00005555555b5178 in rte_security_attach_session (op=0x7fffe8a90008, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:414
 #2  0x00005555555b6389 in ipsec_enqueue (xform_func=0x5555555b7961 <esp_inbound>, ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, sas=0x7fffffffd830,
     nb_pkts=1) at /root/dpdk/examples/ipsec-secgw/ipsec.c:449
 #3  0x00005555555b68f5 in ipsec_inbound (ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, nb_pkts=1, len=32) at /root/dpdk/examples/ipsec-secgw/ipsec.c:542
 #4  0x00005555555c3713 in process_pkts_inbound (ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, traffic=0x7fffffffd8f0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:465
 #5  0x00005555555c42eb in process_pkts (qconf=0x555556001480 <lcore_conf+1680384>, pkts=0x7fffffffe830, nb_pkts=1 '\001', portid=0)
     at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:699
 #6  0x00005555555c47eb in main_loop (dummy=0x0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:792
 #7  0x00005555556301c5 in rte_eal_mp_remote_launch (f=0x5555555c43e8 <main_loop>, arg=0x0, call_master=CALL_MASTER) at /root/dpdk/lib/librte_eal/common/eal_common_launch.c:91
 #8  0x00005555555c65a3 in main (argc=8, argv=0x7fffffffeb18) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:1608

Thanks,

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support

[Anoob]

Hi Nelio,

Which mode was attempted when you got the crash? Is it with inline-protocol?

Thanks,

Anoob


On 11/22/2017 05:51 PM, Nelio Laranjeiro wrote:
> Hi Anoob,
>
> I am facing a segfault in ipsec-secgw with this series when using MLX5
> PMD, maybe you can help here, see the following gdb backtrace.
>
>   Thread 1 "ipsec-secgw" received signal SIGSEGV, Segmentation fault.
>   0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>   378             sym_op->sec_session = sess;
>   (gdb) bt
>   #0  0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>   #1  0x00005555555b5178 in rte_security_attach_session (op=0x7fffe8a90008, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:414
>   #2  0x00005555555b6389 in ipsec_enqueue (xform_func=0x5555555b7961 <esp_inbound>, ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, sas=0x7fffffffd830,
>       nb_pkts=1) at /root/dpdk/examples/ipsec-secgw/ipsec.c:449
>   #3  0x00005555555b68f5 in ipsec_inbound (ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, nb_pkts=1, len=32) at /root/dpdk/examples/ipsec-secgw/ipsec.c:542
>   #4  0x00005555555c3713 in process_pkts_inbound (ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, traffic=0x7fffffffd8f0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:465
>   #5  0x00005555555c42eb in process_pkts (qconf=0x555556001480 <lcore_conf+1680384>, pkts=0x7fffffffe830, nb_pkts=1 '\001', portid=0)
>       at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:699
>   #6  0x00005555555c47eb in main_loop (dummy=0x0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:792
>   #7  0x00005555556301c5 in rte_eal_mp_remote_launch (f=0x5555555c43e8 <main_loop>, arg=0x0, call_master=CALL_MASTER) at /root/dpdk/lib/librte_eal/common/eal_common_launch.c:91
>   #8  0x00005555555c65a3 in main (argc=8, argv=0x7fffffffeb18) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:1608
>
> Thanks,
>

Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support

[Nelio Laranjeiro]

On Wed, Nov 22, 2017 at 06:25:12PM +0530, Anoob wrote:
> Hi Nelio,
> 
> Which mode was attempted when you got the crash? Is it with inline-protocol?

Hi Annoob,

Yes, MLX5 ConnectX-4 Lx INNOVA is an inline crypto NIC.

> Thanks,
> 
> Anoob
> 
> 
> On 11/22/2017 05:51 PM, Nelio Laranjeiro wrote:
> > Hi Anoob,
> > 
> > I am facing a segfault in ipsec-secgw with this series when using MLX5
> > PMD, maybe you can help here, see the following gdb backtrace.
> > 
> >   Thread 1 "ipsec-secgw" received signal SIGSEGV, Segmentation fault.
> >   0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
> >   378             sym_op->sec_session = sess;
> >   (gdb) bt
> >   #0  0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
> >   #1  0x00005555555b5178 in rte_security_attach_session (op=0x7fffe8a90008, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:414
> >   #2  0x00005555555b6389 in ipsec_enqueue (xform_func=0x5555555b7961 <esp_inbound>, ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, sas=0x7fffffffd830,
> >       nb_pkts=1) at /root/dpdk/examples/ipsec-secgw/ipsec.c:449
> >   #3  0x00005555555b68f5 in ipsec_inbound (ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, nb_pkts=1, len=32) at /root/dpdk/examples/ipsec-secgw/ipsec.c:542
> >   #4  0x00005555555c3713 in process_pkts_inbound (ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, traffic=0x7fffffffd8f0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:465
> >   #5  0x00005555555c42eb in process_pkts (qconf=0x555556001480 <lcore_conf+1680384>, pkts=0x7fffffffe830, nb_pkts=1 '\001', portid=0)
> >       at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:699
> >   #6  0x00005555555c47eb in main_loop (dummy=0x0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:792
> >   #7  0x00005555556301c5 in rte_eal_mp_remote_launch (f=0x5555555c43e8 <main_loop>, arg=0x0, call_master=CALL_MASTER) at /root/dpdk/lib/librte_eal/common/eal_common_launch.c:91
> >   #8  0x00005555555c65a3 in main (argc=8, argv=0x7fffffffeb18) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:1608
> > 
> > Thanks,
> > 
> 

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support

[Anoob]

Hi Nelio,

So you had attempted inline-crypto(not inline-protocol), right?

Can you give some more details on the test case which caused the issue? 
Was it inbound or outbound?

And your PMD doesn't have "get_pkt_metadata" function pointer 
registered, right?

Thanks,
Anoob

On 11/22/2017 06:35 PM, Nelio Laranjeiro wrote:
> On Wed, Nov 22, 2017 at 06:25:12PM +0530, Anoob wrote:
>> Hi Nelio,
>>
>> Which mode was attempted when you got the crash? Is it with inline-protocol?
> Hi Annoob,
>
> Yes, MLX5 ConnectX-4 Lx INNOVA is an inline crypto NIC.
>
>> Thanks,
>>
>> Anoob
>>
>>
>> On 11/22/2017 05:51 PM, Nelio Laranjeiro wrote:
>>> Hi Anoob,
>>>
>>> I am facing a segfault in ipsec-secgw with this series when using MLX5
>>> PMD, maybe you can help here, see the following gdb backtrace.
>>>
>>>    Thread 1 "ipsec-secgw" received signal SIGSEGV, Segmentation fault.
>>>    0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>>>    378             sym_op->sec_session = sess;
>>>    (gdb) bt
>>>    #0  0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>>>    #1  0x00005555555b5178 in rte_security_attach_session (op=0x7fffe8a90008, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:414
>>>    #2  0x00005555555b6389 in ipsec_enqueue (xform_func=0x5555555b7961 <esp_inbound>, ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, sas=0x7fffffffd830,
>>>        nb_pkts=1) at /root/dpdk/examples/ipsec-secgw/ipsec.c:449
>>>    #3  0x00005555555b68f5 in ipsec_inbound (ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, nb_pkts=1, len=32) at /root/dpdk/examples/ipsec-secgw/ipsec.c:542
>>>    #4  0x00005555555c3713 in process_pkts_inbound (ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, traffic=0x7fffffffd8f0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:465
>>>    #5  0x00005555555c42eb in process_pkts (qconf=0x555556001480 <lcore_conf+1680384>, pkts=0x7fffffffe830, nb_pkts=1 '\001', portid=0)
>>>        at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:699
>>>    #6  0x00005555555c47eb in main_loop (dummy=0x0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:792
>>>    #7  0x00005555556301c5 in rte_eal_mp_remote_launch (f=0x5555555c43e8 <main_loop>, arg=0x0, call_master=CALL_MASTER) at /root/dpdk/lib/librte_eal/common/eal_common_launch.c:91
>>>    #8  0x00005555555c65a3 in main (argc=8, argv=0x7fffffffeb18) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:1608
>>>
>>> Thanks,
>>>

Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support

[Anoob]

Hi Nelio,

Please ignore the previous mail. I'll check the issue and let you know.


Thanks,
Anoob

On 11/22/2017 07:08 PM, Anoob wrote:
> Hi Nelio,
>
> So you had attempted inline-crypto(not inline-protocol), right?
>
> Can you give some more details on the test case which caused the 
> issue? Was it inbound or outbound?
>
> And your PMD doesn't have "get_pkt_metadata" function pointer 
> registered, right?
>
> Thanks,
> Anoob
>
> On 11/22/2017 06:35 PM, Nelio Laranjeiro wrote:
>> On Wed, Nov 22, 2017 at 06:25:12PM +0530, Anoob wrote:
>>> Hi Nelio,
>>>
>>> Which mode was attempted when you got the crash? Is it with 
>>> inline-protocol?
>> Hi Annoob,
>>
>> Yes, MLX5 ConnectX-4 Lx INNOVA is an inline crypto NIC.
>>
>>> Thanks,
>>>
>>> Anoob
>>>
>>>
>>> On 11/22/2017 05:51 PM, Nelio Laranjeiro wrote:
>>>> Hi Anoob,
>>>>
>>>> I am facing a segfault in ipsec-secgw with this series when using MLX5
>>>> PMD, maybe you can help here, see the following gdb backtrace.
>>>>
>>>>    Thread 1 "ipsec-secgw" received signal SIGSEGV, Segmentation fault.
>>>>    0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, 
>>>> sess=0x7ffef7edb540) at 
>>>> /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>>>>    378             sym_op->sec_session = sess;
>>>>    (gdb) bt
>>>>    #0  0x00005555555b5123 in __rte_security_attach_session 
>>>> (sym_op=0x0, sess=0x7ffef7edb540) at 
>>>> /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>>>>    #1  0x00005555555b5178 in rte_security_attach_session 
>>>> (op=0x7fffe8a90008, sess=0x7ffef7edb540) at 
>>>> /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:414
>>>>    #2  0x00005555555b6389 in ipsec_enqueue 
>>>> (xform_func=0x5555555b7961 <esp_inbound>, ipsec_ctx=0x555556003a00 
>>>> <lcore_conf+1689984>, pkts=0x7fffffffdaf0, sas=0x7fffffffd830,
>>>>        nb_pkts=1) at /root/dpdk/examples/ipsec-secgw/ipsec.c:449
>>>>    #3  0x00005555555b68f5 in ipsec_inbound (ctx=0x555556003a00 
>>>> <lcore_conf+1689984>, pkts=0x7fffffffdaf0, nb_pkts=1, len=32) at 
>>>> /root/dpdk/examples/ipsec-secgw/ipsec.c:542
>>>>    #4  0x00005555555c3713 in process_pkts_inbound 
>>>> (ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, 
>>>> traffic=0x7fffffffd8f0) at 
>>>> /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:465
>>>>    #5  0x00005555555c42eb in process_pkts (qconf=0x555556001480 
>>>> <lcore_conf+1680384>, pkts=0x7fffffffe830, nb_pkts=1 '\001', portid=0)
>>>>        at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:699
>>>>    #6  0x00005555555c47eb in main_loop (dummy=0x0) at 
>>>> /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:792
>>>>    #7  0x00005555556301c5 in rte_eal_mp_remote_launch 
>>>> (f=0x5555555c43e8 <main_loop>, arg=0x0, call_master=CALL_MASTER) at 
>>>> /root/dpdk/lib/librte_eal/common/eal_common_launch.c:91
>>>>    #8  0x00005555555c65a3 in main (argc=8, argv=0x7fffffffeb18) at 
>>>> /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:1608
>>>>
>>>> Thanks,
>>>>
>

Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support

[Anoob]

Hi Nelio,

The issue is probably because of a different patch titled, "[PATCH 2/3] 
crypto: fix pedentic compilation errors". I was able to reproduce the 
issue with that.

Hope this helps.

Thanks,
Anoob

On 11/22/2017 06:35 PM, Nelio Laranjeiro wrote:
> On Wed, Nov 22, 2017 at 06:25:12PM +0530, Anoob wrote:
>> Hi Nelio,
>>
>> Which mode was attempted when you got the crash? Is it with inline-protocol?
> Hi Annoob,
>
> Yes, MLX5 ConnectX-4 Lx INNOVA is an inline crypto NIC.
>
>> Thanks,
>>
>> Anoob
>>
>>
>> On 11/22/2017 05:51 PM, Nelio Laranjeiro wrote:
>>> Hi Anoob,
>>>
>>> I am facing a segfault in ipsec-secgw with this series when using MLX5
>>> PMD, maybe you can help here, see the following gdb backtrace.
>>>
>>>    Thread 1 "ipsec-secgw" received signal SIGSEGV, Segmentation fault.
>>>    0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>>>    378             sym_op->sec_session = sess;
>>>    (gdb) bt
>>>    #0  0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>>>    #1  0x00005555555b5178 in rte_security_attach_session (op=0x7fffe8a90008, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:414
>>>    #2  0x00005555555b6389 in ipsec_enqueue (xform_func=0x5555555b7961 <esp_inbound>, ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, sas=0x7fffffffd830,
>>>        nb_pkts=1) at /root/dpdk/examples/ipsec-secgw/ipsec.c:449
>>>    #3  0x00005555555b68f5 in ipsec_inbound (ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, nb_pkts=1, len=32) at /root/dpdk/examples/ipsec-secgw/ipsec.c:542
>>>    #4  0x00005555555c3713 in process_pkts_inbound (ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, traffic=0x7fffffffd8f0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:465
>>>    #5  0x00005555555c42eb in process_pkts (qconf=0x555556001480 <lcore_conf+1680384>, pkts=0x7fffffffe830, nb_pkts=1 '\001', portid=0)
>>>        at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:699
>>>    #6  0x00005555555c47eb in main_loop (dummy=0x0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:792
>>>    #7  0x00005555556301c5 in rte_eal_mp_remote_launch (f=0x5555555c43e8 <main_loop>, arg=0x0, call_master=CALL_MASTER) at /root/dpdk/lib/librte_eal/common/eal_common_launch.c:91
>>>    #8  0x00005555555c65a3 in main (argc=8, argv=0x7fffffffeb18) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:1608
>>>
>>> Thanks,
>>>

Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support

[Nelio Laranjeiro]

On Wed, Nov 22, 2017 at 08:43:29PM +0530, Anoob wrote:
>    Hi Nelio,
> 
>    The issue is probably because of a different patch titled, "[PATCH 2/3]
>    crypto: fix pedentic compilation errors". I was able to reproduce the
>    issue with that.
> 
>    Hope this helps.
> 
>    Thanks,
>    Anoob

Hi Anoob,

Indeed, and I am the author for this one, I've tested your series on top
of the it by replacing the RTE_STD_C11 by __extentsion__ which fixes the
pedantic compilation also, I don't have anymore the segfault.

Thanks and sorry for this,

>    On 11/22/2017 06:35 PM, Nelio Laranjeiro wrote:
> 
>  On Wed, Nov 22, 2017 at 06:25:12PM +0530, Anoob wrote:
> 
>  Hi Nelio,
> 
>  Which mode was attempted when you got the crash? Is it with inline-protocol?
> 
>  Hi Annoob,
> 
>  Yes, MLX5 ConnectX-4 Lx INNOVA is an inline crypto NIC.
> 
> 
>  Thanks,
> 
>  Anoob
> 
> 
>  On 11/22/2017 05:51 PM, Nelio Laranjeiro wrote:
> 
>  Hi Anoob,
> 
>  I am facing a segfault in ipsec-secgw with this series when using MLX5
>  PMD, maybe you can help here, see the following gdb backtrace.
> 
>    Thread 1 "ipsec-secgw" received signal SIGSEGV, Segmentation fault.
>    0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>    378             sym_op->sec_session = sess;
>    (gdb) bt
>    #0  0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>    #1  0x00005555555b5178 in rte_security_attach_session (op=0x7fffe8a90008, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:414
>    #2  0x00005555555b6389 in ipsec_enqueue (xform_func=0x5555555b7961 <esp_inbound>, ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, sas=0x7fffffffd830,
>        nb_pkts=1) at /root/dpdk/examples/ipsec-secgw/ipsec.c:449
>    #3  0x00005555555b68f5 in ipsec_inbound (ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, nb_pkts=1, len=32) at /root/dpdk/examples/ipsec-secgw/ipsec.c:542
>    #4  0x00005555555c3713 in process_pkts_inbound (ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, traffic=0x7fffffffd8f0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:465
>    #5  0x00005555555c42eb in process_pkts (qconf=0x555556001480 <lcore_conf+1680384>, pkts=0x7fffffffe830, nb_pkts=1 '\001', portid=0)
>        at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:699
>    #6  0x00005555555c47eb in main_loop (dummy=0x0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:792
>    #7  0x00005555556301c5 in rte_eal_mp_remote_launch (f=0x5555555c43e8 <main_loop>, arg=0x0, call_master=CALL_MASTER) at /root/dpdk/lib/librte_eal/common/eal_common_launch.c:91
>    #8  0x00005555555c65a3 in main (argc=8, argv=0x7fffffffeb18) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:1608
> 
>  Thanks,

-- 
Nélio Laranjeiro
6WIND

[dpdk-dev] [PATCH v3 0/2] add inline protocol support

[Anoob Joseph]

The series adds inline protocol support in ipsec-secgw application.

First patch introduces changes in lib to enable applications to save a
(void *) pointer as "userdata" in security session. For inline processed
packets, application could call "rte_security_get_pkt_metadata" API to
retrieve this application registered userdata from the packet. API
will return the userdata associated with the security session which
processed the packet.

This is primarily required for inline protocol processed ingress
packets. For such packets, the packet may not have enough information to
identify the security parameters with which the packet was processed.
Application can register what it needs to identify the required
parameter. The userdata will be set while creating the security
session.

Second patch adds support for inline protocol in ipsec-secgw
application.

Anoob Joseph (2):
  lib/security: add support for get metadata
  examples/ipsec-secgw: add support for inline protocol

 examples/ipsec-secgw/esp.c                |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c        |  40 +++++++++-
 examples/ipsec-secgw/ipsec.c              | 121 +++++++++++++++++++++++++-----
 lib/librte_security/rte_security.c        |  13 ++++
 lib/librte_security/rte_security.h        |  19 +++++
 lib/librte_security/rte_security_driver.h |  16 ++++
 6 files changed, 193 insertions(+), 22 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Anoob Joseph]

In case of inline protocol processed ingress traffic, the packet may not
have enough information to determine the security parameters with which
the packet was processed. In such cases, application could get metadata
from the packet which could be used to identify the security parameters
with which the packet was processed.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v3:
* Replaced 64 bit metadata in conf with (void *)userdata
* The API(rte_security_get_pkt_metadata) would return void * instead of
  uint64_t

v2:
* Replaced get_session and get_cookie APIs with get_pkt_metadata API

 lib/librte_security/rte_security.c        | 13 +++++++++++++
 lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
 lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
 3 files changed, 48 insertions(+)

diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
index 1227fca..a1d78b6 100644
--- a/lib/librte_security/rte_security.c
+++ b/lib/librte_security/rte_security.c
@@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 					       sess, m, params);
 }
 
+void *
+rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
+			      struct rte_mbuf *pkt)
+{
+	void *md = NULL;
+
+	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
+	if (instance->ops->get_pkt_metadata(instance->device, pkt, &md))
+		return NULL;
+
+	return md;
+}
+
 const struct rte_security_capability *
 rte_security_capabilities_get(struct rte_security_ctx *instance)
 {
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index 653929b..35c306a 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -274,6 +274,8 @@ struct rte_security_session_conf {
 	/**< Configuration parameters for security session */
 	struct rte_crypto_sym_xform *crypto_xform;
 	/**< Security Session Crypto Transformations */
+	void *userdata;
+	/**< Application specific metadata */
 };
 
 struct rte_security_session {
@@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 			      struct rte_mbuf *mb, void *params);
 
 /**
+ * Get metadata from the packet. This returns metadata associated with the
+ * security session which processed the packet.
+ *
+ * This is valid only for inline processed ingress packets.
+ *
+ * @param   instance	security instance
+ * @param   pkt		packet mbuf
+ *
+ * @return
+ *  - On success, metadata
+ *  - On failure, NULL
+ */
+void *
+rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
+			      struct rte_mbuf *pkt);
+
+/**
  * Attach a session to a symmetric crypto operation
  *
  * @param	sym_op	crypto operation
diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
index 997fbe7..561ae83 100644
--- a/lib/librte_security/rte_security_driver.h
+++ b/lib/librte_security/rte_security_driver.h
@@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
 		void *params);
 
 /**
+ * Get metadata from the packet.
+ *
+ * @param	device		Crypto/eth device pointer
+ * @param	pkt		Packet mbuf
+ * @param	mt		Pointer to receive metadata
+ *
+ * @return
+ *  - Returns 0 if metadata is retrieved successfully.
+ *  - Returns -ve value for errors.
+ */
+typedef int (*security_get_pkt_metadata_t)(void *device,
+		struct rte_mbuf *pkt, void **md);
+
+/**
  * Get security capabilities of the device.
  *
  * @param	device		crypto/eth device pointer
@@ -145,6 +159,8 @@ struct rte_security_ops {
 	/**< Clear a security sessions private data. */
 	security_set_pkt_metadata_t set_pkt_metadata;
 	/**< Update mbuf metadata. */
+	security_get_pkt_metadata_t get_pkt_metadata;
+	/**< Get metadata from packet. */
 	security_capabilities_get_t capabilities_get;
 	/**< Get security capabilities. */
 };
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Akhil Goyal]

Hi Anoob, Radu,
On 11/23/2017 4:49 PM, Anoob Joseph wrote:
> In case of inline protocol processed ingress traffic, the packet may not
> have enough information to determine the security parameters with which
> the packet was processed. In such cases, application could get metadata
> from the packet which could be used to identify the security parameters
> with which the packet was processed.
> 
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
> v3:
> * Replaced 64 bit metadata in conf with (void *)userdata
> * The API(rte_security_get_pkt_metadata) would return void * instead of
>    uint64_t
> 
> v2:
> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
> 
>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>   3 files changed, 48 insertions(+)
> 
> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> index 1227fca..a1d78b6 100644
> --- a/lib/librte_security/rte_security.c
> +++ b/lib/librte_security/rte_security.c
> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>   					       sess, m, params);
>   }
>   
> +void *
> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
> +			      struct rte_mbuf *pkt)
Can we rename pkt with m. Just to make it consistent with the set API.
> +{
> +	void *md = NULL;
> +
> +	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
> +	if (instance->ops->get_pkt_metadata(instance->device, pkt, &md))
> +		return NULL;
> +
> +	return md;
> +}

Pkt metadata should be set by user i.e. the application, and the driver 
need not be aware of the format and the values of the metadata.
So setting the metadata in the driver and getting it back from the 
driver does not look a good idea.

Is it possible, that the application define the metadata on its own and 
set it in the library itself without the call to the driver ops.

> +
>   const struct rte_security_capability *
>   rte_security_capabilities_get(struct rte_security_ctx *instance)
>   {
> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> index 653929b..35c306a 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -274,6 +274,8 @@ struct rte_security_session_conf {
>   	/**< Configuration parameters for security session */
>   	struct rte_crypto_sym_xform *crypto_xform;
>   	/**< Security Session Crypto Transformations */
> +	void *userdata;
> +	/**< Application specific metadata */
>   };
>   
>   struct rte_security_session {
> @@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>   			      struct rte_mbuf *mb, void *params);
>   
>   /**
> + * Get metadata from the packet. This returns metadata associated with the
> + * security session which processed the packet.
> + *
> + * This is valid only for inline processed ingress packets.
> + *
> + * @param   instance	security instance
> + * @param   pkt		packet mbuf
> + *
> + * @return
> + *  - On success, metadata
> + *  - On failure, NULL
> + */
> +void *
> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
> +			      struct rte_mbuf *pkt);
> +
> +/**
>    * Attach a session to a symmetric crypto operation
>    *
>    * @param	sym_op	crypto operation
> diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
> index 997fbe7..561ae83 100644
> --- a/lib/librte_security/rte_security_driver.h
> +++ b/lib/librte_security/rte_security_driver.h
> @@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
>   		void *params);
>   
>   /**
> + * Get metadata from the packet.
> + *
> + * @param	device		Crypto/eth device pointer
> + * @param	pkt		Packet mbuf
> + * @param	mt		Pointer to receive metadata
> + *
> + * @return
> + *  - Returns 0 if metadata is retrieved successfully.
> + *  - Returns -ve value for errors.
> + */
> +typedef int (*security_get_pkt_metadata_t)(void *device,
> +		struct rte_mbuf *pkt, void **md);
> +
> +/**
>    * Get security capabilities of the device.
>    *
>    * @param	device		crypto/eth device pointer
> @@ -145,6 +159,8 @@ struct rte_security_ops {
>   	/**< Clear a security sessions private data. */
>   	security_set_pkt_metadata_t set_pkt_metadata;
>   	/**< Update mbuf metadata. */
> +	security_get_pkt_metadata_t get_pkt_metadata;
> +	/**< Get metadata from packet. */
>   	security_capabilities_get_t capabilities_get;
>   	/**< Get security capabilities. */
>   };
> 

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Radu Nicolau]

Hi,

Comment inline


On 11/24/2017 8:50 AM, Akhil Goyal wrote:
> Hi Anoob, Radu,
> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>> In case of inline protocol processed ingress traffic, the packet may not
>> have enough information to determine the security parameters with which
>> the packet was processed. In such cases, application could get metadata
>> from the packet which could be used to identify the security parameters
>> with which the packet was processed.
>>
>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> ---
>> v3:
>> * Replaced 64 bit metadata in conf with (void *)userdata
>> * The API(rte_security_get_pkt_metadata) would return void * instead of
>>    uint64_t
>>
>> v2:
>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>
>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>   3 files changed, 48 insertions(+)
>>
>> diff --git a/lib/librte_security/rte_security.c 
>> b/lib/librte_security/rte_security.c
>> index 1227fca..a1d78b6 100644
>> --- a/lib/librte_security/rte_security.c
>> +++ b/lib/librte_security/rte_security.c
>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>> rte_security_ctx *instance,
>>                              sess, m, params);
>>   }
>>   +void *
>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>> +                  struct rte_mbuf *pkt)
> Can we rename pkt with m. Just to make it consistent with the set API.
>> +{
>> +    void *md = NULL;
>> +
>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, &md))
>> +        return NULL;
>> +
>> +    return md;
>> +}
>
> Pkt metadata should be set by user i.e. the application, and the 
> driver need not be aware of the format and the values of the metadata.
> So setting the metadata in the driver and getting it back from the 
> driver does not look a good idea.
>
> Is it possible, that the application define the metadata on its own 
> and set it in the library itself without the call to the driver ops.
I'm not sure I understand here; even in our case (ixgbe) the driver sets 
the metadata and it is aware of the format - that is the whole idea. 
This is why we added the set_metadata API, to allow the driver to inject 
extra information into the mbuf, information that is driver specific and 
derived from the security session, so it makes sense to also have a 
symmetric get_metadata.
Private data is the one that follows those rules, i.e. application 
specific and driver transparent.
>
>> +
>>   const struct rte_security_capability *
>>   rte_security_capabilities_get(struct rte_security_ctx *instance)
>>   {
>> diff --git a/lib/librte_security/rte_security.h 
>> b/lib/librte_security/rte_security.h
>> index 653929b..35c306a 100644
>> --- a/lib/librte_security/rte_security.h
>> +++ b/lib/librte_security/rte_security.h
>> @@ -274,6 +274,8 @@ struct rte_security_session_conf {
>>       /**< Configuration parameters for security session */
>>       struct rte_crypto_sym_xform *crypto_xform;
>>       /**< Security Session Crypto Transformations */
>> +    void *userdata;
>> +    /**< Application specific metadata */
>>   };
>>     struct rte_security_session {
>> @@ -346,6 +348,23 @@ rte_security_set_pkt_metadata(struct 
>> rte_security_ctx *instance,
>>                     struct rte_mbuf *mb, void *params);
>>     /**
>> + * Get metadata from the packet. This returns metadata associated 
>> with the
>> + * security session which processed the packet.
>> + *
>> + * This is valid only for inline processed ingress packets.
>> + *
>> + * @param   instance    security instance
>> + * @param   pkt        packet mbuf
>> + *
>> + * @return
>> + *  - On success, metadata
>> + *  - On failure, NULL
>> + */
>> +void *
>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>> +                  struct rte_mbuf *pkt);
>> +
>> +/**
>>    * Attach a session to a symmetric crypto operation
>>    *
>>    * @param    sym_op    crypto operation
>> diff --git a/lib/librte_security/rte_security_driver.h 
>> b/lib/librte_security/rte_security_driver.h
>> index 997fbe7..561ae83 100644
>> --- a/lib/librte_security/rte_security_driver.h
>> +++ b/lib/librte_security/rte_security_driver.h
>> @@ -122,6 +122,20 @@ typedef int (*security_set_pkt_metadata_t)(void 
>> *device,
>>           void *params);
>>     /**
>> + * Get metadata from the packet.
>> + *
>> + * @param    device        Crypto/eth device pointer
>> + * @param    pkt        Packet mbuf
>> + * @param    mt        Pointer to receive metadata
>> + *
>> + * @return
>> + *  - Returns 0 if metadata is retrieved successfully.
>> + *  - Returns -ve value for errors.
>> + */
>> +typedef int (*security_get_pkt_metadata_t)(void *device,
>> +        struct rte_mbuf *pkt, void **md);
>> +
>> +/**
>>    * Get security capabilities of the device.
>>    *
>>    * @param    device        crypto/eth device pointer
>> @@ -145,6 +159,8 @@ struct rte_security_ops {
>>       /**< Clear a security sessions private data. */
>>       security_set_pkt_metadata_t set_pkt_metadata;
>>       /**< Update mbuf metadata. */
>> +    security_get_pkt_metadata_t get_pkt_metadata;
>> +    /**< Get metadata from packet. */
>>       security_capabilities_get_t capabilities_get;
>>       /**< Get security capabilities. */
>>   };
>>
>

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Akhil Goyal]

On 11/24/2017 3:09 PM, Radu Nicolau wrote:
> Hi,
> 
> Comment inline
> 
> 
> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>> Hi Anoob, Radu,
>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>> In case of inline protocol processed ingress traffic, the packet may not
>>> have enough information to determine the security parameters with which
>>> the packet was processed. In such cases, application could get metadata
>>> from the packet which could be used to identify the security parameters
>>> with which the packet was processed.
>>>
>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>> ---
>>> v3:
>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>> * The API(rte_security_get_pkt_metadata) would return void * instead of
>>>    uint64_t
>>>
>>> v2:
>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>>
>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>   3 files changed, 48 insertions(+)
>>>
>>> diff --git a/lib/librte_security/rte_security.c 
>>> b/lib/librte_security/rte_security.c
>>> index 1227fca..a1d78b6 100644
>>> --- a/lib/librte_security/rte_security.c
>>> +++ b/lib/librte_security/rte_security.c
>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>> rte_security_ctx *instance,
>>>                              sess, m, params);
>>>   }
>>>   +void *
>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>> +                  struct rte_mbuf *pkt)
>> Can we rename pkt with m. Just to make it consistent with the set API.
>>> +{
>>> +    void *md = NULL;
>>> +
>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, &md))
>>> +        return NULL;
>>> +
>>> +    return md;
>>> +}
>>
>> Pkt metadata should be set by user i.e. the application, and the 
>> driver need not be aware of the format and the values of the metadata.
>> So setting the metadata in the driver and getting it back from the 
>> driver does not look a good idea.
>>
>> Is it possible, that the application define the metadata on its own 
>> and set it in the library itself without the call to the driver ops.
> I'm not sure I understand here; even in our case (ixgbe) the driver sets 
> the metadata and it is aware of the format - that is the whole idea. 
> This is why we added the set_metadata API, to allow the driver to inject 
> extra information into the mbuf, information that is driver specific and 
> derived from the security session, so it makes sense to also have a 
> symmetric get_metadata.
> Private data is the one that follows those rules, i.e. application 
> specific and driver transparent.

As per my understanding of the user metadata, it should be in control of 
the application, and the application shall know the format of that. 
Setting in driver will disallow this.
Please let me know if my understanding is incorrect.

If at all, some information is needed to be set on the basis of driver, 
then application can get that information from the driver and then set 
it in the packet metadata in its own way/format.

-Akhil

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Radu Nicolau]

On 11/24/2017 10:55 AM, Akhil Goyal wrote:
> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>> Hi,
>>
>> Comment inline
>>
>>
>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>> Hi Anoob, Radu,
>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>> In case of inline protocol processed ingress traffic, the packet 
>>>> may not
>>>> have enough information to determine the security parameters with 
>>>> which
>>>> the packet was processed. In such cases, application could get 
>>>> metadata
>>>> from the packet which could be used to identify the security 
>>>> parameters
>>>> with which the packet was processed.
>>>>
>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>> ---
>>>> v3:
>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>> instead of
>>>>    uint64_t
>>>>
>>>> v2:
>>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>>>
>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>   3 files changed, 48 insertions(+)
>>>>
>>>> diff --git a/lib/librte_security/rte_security.c 
>>>> b/lib/librte_security/rte_security.c
>>>> index 1227fca..a1d78b6 100644
>>>> --- a/lib/librte_security/rte_security.c
>>>> +++ b/lib/librte_security/rte_security.c
>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>> rte_security_ctx *instance,
>>>>                              sess, m, params);
>>>>   }
>>>>   +void *
>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>> +                  struct rte_mbuf *pkt)
>>> Can we rename pkt with m. Just to make it consistent with the set API.
>>>> +{
>>>> +    void *md = NULL;
>>>> +
>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, &md))
>>>> +        return NULL;
>>>> +
>>>> +    return md;
>>>> +}
>>>
>>> Pkt metadata should be set by user i.e. the application, and the 
>>> driver need not be aware of the format and the values of the metadata.
>>> So setting the metadata in the driver and getting it back from the 
>>> driver does not look a good idea.
>>>
>>> Is it possible, that the application define the metadata on its own 
>>> and set it in the library itself without the call to the driver ops.
>> I'm not sure I understand here; even in our case (ixgbe) the driver 
>> sets the metadata and it is aware of the format - that is the whole 
>> idea. This is why we added the set_metadata API, to allow the driver 
>> to inject extra information into the mbuf, information that is driver 
>> specific and derived from the security session, so it makes sense to 
>> also have a symmetric get_metadata.
>> Private data is the one that follows those rules, i.e. application 
>> specific and driver transparent.
>
> As per my understanding of the user metadata, it should be in control 
> of the application, and the application shall know the format of that. 
> Setting in driver will disallow this.
> Please let me know if my understanding is incorrect.
>
> If at all, some information is needed to be set on the basis of 
> driver, then application can get that information from the driver and 
> then set it in the packet metadata in its own way/format.

The rte_security_set_pkt_metadata() doc defines the metadata as 
"device-specific defined metadata" and also takes a device specific 
params pointer, so the symmetric function is to be expected to work in 
the same way, i.e. return device specific metadata associated with the 
security session and instance and mbuf. How is this metadata stored is 
not specified in the security API, so the PMD implementation have the 
flexibility.

>
> -Akhil

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Akhil Goyal]

Hi Radu,
On 11/24/2017 4:47 PM, Radu Nicolau wrote:
> 
> 
> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>> Hi,
>>>
>>> Comment inline
>>>
>>>
>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>> Hi Anoob, Radu,
>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>> In case of inline protocol processed ingress traffic, the packet 
>>>>> may not
>>>>> have enough information to determine the security parameters with 
>>>>> which
>>>>> the packet was processed. In such cases, application could get 
>>>>> metadata
>>>>> from the packet which could be used to identify the security 
>>>>> parameters
>>>>> with which the packet was processed.
>>>>>
>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>> ---
>>>>> v3:
>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>> instead of
>>>>>    uint64_t
>>>>>
>>>>> v2:
>>>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>>>>
>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>>   3 files changed, 48 insertions(+)
>>>>>
>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>> b/lib/librte_security/rte_security.c
>>>>> index 1227fca..a1d78b6 100644
>>>>> --- a/lib/librte_security/rte_security.c
>>>>> +++ b/lib/librte_security/rte_security.c
>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>> rte_security_ctx *instance,
>>>>>                              sess, m, params);
>>>>>   }
>>>>>   +void *
>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>> +                  struct rte_mbuf *pkt)
>>>> Can we rename pkt with m. Just to make it consistent with the set API.
>>>>> +{
>>>>> +    void *md = NULL;
>>>>> +
>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, &md))
>>>>> +        return NULL;
>>>>> +
>>>>> +    return md;
>>>>> +}
>>>>
>>>> Pkt metadata should be set by user i.e. the application, and the 
>>>> driver need not be aware of the format and the values of the metadata.
>>>> So setting the metadata in the driver and getting it back from the 
>>>> driver does not look a good idea.
>>>>
>>>> Is it possible, that the application define the metadata on its own 
>>>> and set it in the library itself without the call to the driver ops.
>>> I'm not sure I understand here; even in our case (ixgbe) the driver 
>>> sets the metadata and it is aware of the format - that is the whole 
>>> idea. This is why we added the set_metadata API, to allow the driver 
>>> to inject extra information into the mbuf, information that is driver 
>>> specific and derived from the security session, so it makes sense to 
>>> also have a symmetric get_metadata.
>>> Private data is the one that follows those rules, i.e. application 
>>> specific and driver transparent.
>>
>> As per my understanding of the user metadata, it should be in control 
>> of the application, and the application shall know the format of that. 
>> Setting in driver will disallow this.
>> Please let me know if my understanding is incorrect.
>>
>> If at all, some information is needed to be set on the basis of 
>> driver, then application can get that information from the driver and 
>> then set it in the packet metadata in its own way/format.
> 
> The rte_security_set_pkt_metadata() doc defines the metadata as 
> "device-specific defined metadata" and also takes a device specific 
> params pointer, so the symmetric function is to be expected to work in 
> the same way, i.e. return device specific metadata associated with the 
> security session and instance and mbuf. How is this metadata stored is 
> not specified in the security API, so the PMD implementation have the 
> flexibility.
> 

Yes it was defined that way and I did not noticed this one at the time 
of it's implementation.
Here, my point is that the application may be using mbuf udata for it's 
own functionality, it should not be modified in the driver.

However, if we need to do this, then we may need to clarify in the 
documentation that for security, udata shall be set with the 
rte_security_set_pkt_metadata() and not otherwise.

-Akhil

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Radu Nicolau]

On 11/24/2017 11:34 AM, Akhil Goyal wrote:
> Hi Radu,
> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>
>>
>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>> Hi,
>>>>
>>>> Comment inline
>>>>
>>>>
>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>> Hi Anoob, Radu,
>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>> In case of inline protocol processed ingress traffic, the packet 
>>>>>> may not
>>>>>> have enough information to determine the security parameters with 
>>>>>> which
>>>>>> the packet was processed. In such cases, application could get 
>>>>>> metadata
>>>>>> from the packet which could be used to identify the security 
>>>>>> parameters
>>>>>> with which the packet was processed.
>>>>>>
>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>> ---
>>>>>> v3:
>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>> instead of
>>>>>>    uint64_t
>>>>>>
>>>>>> v2:
>>>>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>>>>>
>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>>>   3 files changed, 48 insertions(+)
>>>>>>
>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>> b/lib/librte_security/rte_security.c
>>>>>> index 1227fca..a1d78b6 100644
>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>> rte_security_ctx *instance,
>>>>>>                              sess, m, params);
>>>>>>   }
>>>>>>   +void *
>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>>> +                  struct rte_mbuf *pkt)
>>>>> Can we rename pkt with m. Just to make it consistent with the set 
>>>>> API.
>>>>>> +{
>>>>>> +    void *md = NULL;
>>>>>> +
>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, 
>>>>>> &md))
>>>>>> +        return NULL;
>>>>>> +
>>>>>> +    return md;
>>>>>> +}
>>>>>
>>>>> Pkt metadata should be set by user i.e. the application, and the 
>>>>> driver need not be aware of the format and the values of the 
>>>>> metadata.
>>>>> So setting the metadata in the driver and getting it back from the 
>>>>> driver does not look a good idea.
>>>>>
>>>>> Is it possible, that the application define the metadata on its 
>>>>> own and set it in the library itself without the call to the 
>>>>> driver ops.
>>>> I'm not sure I understand here; even in our case (ixgbe) the driver 
>>>> sets the metadata and it is aware of the format - that is the whole 
>>>> idea. This is why we added the set_metadata API, to allow the 
>>>> driver to inject extra information into the mbuf, information that 
>>>> is driver specific and derived from the security session, so it 
>>>> makes sense to also have a symmetric get_metadata.
>>>> Private data is the one that follows those rules, i.e. application 
>>>> specific and driver transparent.
>>>
>>> As per my understanding of the user metadata, it should be in 
>>> control of the application, and the application shall know the 
>>> format of that. Setting in driver will disallow this.
>>> Please let me know if my understanding is incorrect.
>>>
>>> If at all, some information is needed to be set on the basis of 
>>> driver, then application can get that information from the driver 
>>> and then set it in the packet metadata in its own way/format.
>>
>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>> "device-specific defined metadata" and also takes a device specific 
>> params pointer, so the symmetric function is to be expected to work 
>> in the same way, i.e. return device specific metadata associated with 
>> the security session and instance and mbuf. How is this metadata 
>> stored is not specified in the security API, so the PMD 
>> implementation have the flexibility.
>>
>
> Yes it was defined that way and I did not noticed this one at the time 
> of it's implementation.
> Here, my point is that the application may be using mbuf udata for 
> it's own functionality, it should not be modified in the driver.
>
> However, if we need to do this, then we may need to clarify in the 
> documentation that for security, udata shall be set with the 
> rte_security_set_pkt_metadata() and not otherwise.
Indeed, we should update the doc stating that the set_metadata may 
change the mbuf userdata field so the application should use only 
private data if needed.
>
> -Akhil

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Akhil Goyal]

On 11/24/2017 5:29 PM, Radu Nicolau wrote:
> 
> 
> On 11/24/2017 11:34 AM, Akhil Goyal wrote:
>> Hi Radu,
>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>
>>>
>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>> Hi,
>>>>>
>>>>> Comment inline
>>>>>
>>>>>
>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>> Hi Anoob, Radu,
>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>> In case of inline protocol processed ingress traffic, the packet 
>>>>>>> may not
>>>>>>> have enough information to determine the security parameters with 
>>>>>>> which
>>>>>>> the packet was processed. In such cases, application could get 
>>>>>>> metadata
>>>>>>> from the packet which could be used to identify the security 
>>>>>>> parameters
>>>>>>> with which the packet was processed.
>>>>>>>
>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>> ---
>>>>>>> v3:
>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>>> instead of
>>>>>>>    uint64_t
>>>>>>>
>>>>>>> v2:
>>>>>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>>>>>>
>>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>
>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>> rte_security_ctx *instance,
>>>>>>>                              sess, m, params);
>>>>>>>   }
>>>>>>>   +void *
>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>> Can we rename pkt with m. Just to make it consistent with the set 
>>>>>> API.
>>>>>>> +{
>>>>>>> +    void *md = NULL;
>>>>>>> +
>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, 
>>>>>>> &md))
>>>>>>> +        return NULL;
>>>>>>> +
>>>>>>> +    return md;
>>>>>>> +}
>>>>>>
>>>>>> Pkt metadata should be set by user i.e. the application, and the 
>>>>>> driver need not be aware of the format and the values of the 
>>>>>> metadata.
>>>>>> So setting the metadata in the driver and getting it back from the 
>>>>>> driver does not look a good idea.
>>>>>>
>>>>>> Is it possible, that the application define the metadata on its 
>>>>>> own and set it in the library itself without the call to the 
>>>>>> driver ops.
>>>>> I'm not sure I understand here; even in our case (ixgbe) the driver 
>>>>> sets the metadata and it is aware of the format - that is the whole 
>>>>> idea. This is why we added the set_metadata API, to allow the 
>>>>> driver to inject extra information into the mbuf, information that 
>>>>> is driver specific and derived from the security session, so it 
>>>>> makes sense to also have a symmetric get_metadata.
>>>>> Private data is the one that follows those rules, i.e. application 
>>>>> specific and driver transparent.
>>>>
>>>> As per my understanding of the user metadata, it should be in 
>>>> control of the application, and the application shall know the 
>>>> format of that. Setting in driver will disallow this.
>>>> Please let me know if my understanding is incorrect.
>>>>
>>>> If at all, some information is needed to be set on the basis of 
>>>> driver, then application can get that information from the driver 
>>>> and then set it in the packet metadata in its own way/format.
>>>
>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>> "device-specific defined metadata" and also takes a device specific 
>>> params pointer, so the symmetric function is to be expected to work 
>>> in the same way, i.e. return device specific metadata associated with 
>>> the security session and instance and mbuf. How is this metadata 
>>> stored is not specified in the security API, so the PMD 
>>> implementation have the flexibility.
>>>
>>
>> Yes it was defined that way and I did not noticed this one at the time 
>> of it's implementation.
>> Here, my point is that the application may be using mbuf udata for 
>> it's own functionality, it should not be modified in the driver.
>>
>> However, if we need to do this, then we may need to clarify in the 
>> documentation that for security, udata shall be set with the 
>> rte_security_set_pkt_metadata() and not otherwise.
> Indeed, we should update the doc stating that the set_metadata may 
> change the mbuf userdata field so the application should use only 
> private data if needed.

Agreed, but it is dependent on which driver/mode(inline or lookaside), 
it will be used.
Lookaside may not need this API as of now. Other implementations may 
also don't require. So this shall be documented that way.

-Akhil

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Anoob]

Hi Akhil, Radu,

Please see inline.

Thanks,

Anoob


On 11/24/2017 05:33 PM, Akhil Goyal wrote:
> On 11/24/2017 5:29 PM, Radu Nicolau wrote:
>>
>>
>> On 11/24/2017 11:34 AM, Akhil Goyal wrote:
>>> Hi Radu,
>>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>>
>>>>
>>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Comment inline
>>>>>>
>>>>>>
>>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>>> Hi Anoob, Radu,
>>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>>> In case of inline protocol processed ingress traffic, the 
>>>>>>>> packet may not
>>>>>>>> have enough information to determine the security parameters 
>>>>>>>> with which
>>>>>>>> the packet was processed. In such cases, application could get 
>>>>>>>> metadata
>>>>>>>> from the packet which could be used to identify the security 
>>>>>>>> parameters
>>>>>>>> with which the packet was processed.
>>>>>>>>
>>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>>> ---
>>>>>>>> v3:
>>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>>>> instead of
>>>>>>>>    uint64_t
>>>>>>>>
>>>>>>>> v2:
>>>>>>>> * Replaced get_session and get_cookie APIs with 
>>>>>>>> get_pkt_metadata API
>>>>>>>>
>>>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>>>   lib/librte_security/rte_security.h        | 19 
>>>>>>>> +++++++++++++++++++
>>>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>>> rte_security_ctx *instance,
>>>>>>>>                              sess, m, params);
>>>>>>>>   }
>>>>>>>>   +void *
>>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>>> Can we rename pkt with m. Just to make it consistent with the 
>>>>>>> set API.
>>>>>>>> +{
>>>>>>>> +    void *md = NULL;
>>>>>>>> +
>>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, 
>>>>>>>> &md))
>>>>>>>> +        return NULL;
>>>>>>>> +
>>>>>>>> +    return md;
>>>>>>>> +}
>>>>>>>
>>>>>>> Pkt metadata should be set by user i.e. the application, and the 
>>>>>>> driver need not be aware of the format and the values of the 
>>>>>>> metadata.
>>>>>>> So setting the metadata in the driver and getting it back from 
>>>>>>> the driver does not look a good idea.
>>>>>>>
>>>>>>> Is it possible, that the application define the metadata on its 
>>>>>>> own and set it in the library itself without the call to the 
>>>>>>> driver ops.
>>>>>> I'm not sure I understand here; even in our case (ixgbe) the 
>>>>>> driver sets the metadata and it is aware of the format - that is 
>>>>>> the whole idea. This is why we added the set_metadata API, to 
>>>>>> allow the driver to inject extra information into the mbuf, 
>>>>>> information that is driver specific and derived from the security 
>>>>>> session, so it makes sense to also have a symmetric get_metadata.
>>>>>> Private data is the one that follows those rules, i.e. 
>>>>>> application specific and driver transparent.
>>>>>
>>>>> As per my understanding of the user metadata, it should be in 
>>>>> control of the application, and the application shall know the 
>>>>> format of that. Setting in driver will disallow this.
>>>>> Please let me know if my understanding is incorrect.
>>>>>
>>>>> If at all, some information is needed to be set on the basis of 
>>>>> driver, then application can get that information from the driver 
>>>>> and then set it in the packet metadata in its own way/format.
>>>>
>>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>>> "device-specific defined metadata" and also takes a device specific 
>>>> params pointer, so the symmetric function is to be expected to work 
>>>> in the same way, i.e. return device specific metadata associated 
>>>> with the security session and instance and mbuf. How is this 
>>>> metadata stored is not specified in the security API, so the PMD 
>>>> implementation have the flexibility.
Is rte_security_get_pkt_metadata() expected to return a "device 
specific" pointer? If that's the case, we would need another call 
(something like, rte_security_get_userdata()) to get back the userdata, 
right? Or is it fine, if the application assumes it will get userdata 
(the one passed in conf while creating security session) with 
rte_security_get_pkt_metadata()?
>>>>
>>>
>>> Yes it was defined that way and I did not noticed this one at the 
>>> time of it's implementation.
>>> Here, my point is that the application may be using mbuf udata for 
>>> it's own functionality, it should not be modified in the driver.
>>>
>>> However, if we need to do this, then we may need to clarify in the 
>>> documentation that for security, udata shall be set with the 
>>> rte_security_set_pkt_metadata() and not otherwise.
>> Indeed, we should update the doc stating that the set_metadata may 
>> change the mbuf userdata field so the application should use only 
>> private data if needed.
>
> Agreed, but it is dependent on which driver/mode(inline or lookaside), 
> it will be used.
> Lookaside may not need this API as of now. Other implementations may 
> also don't require. So this shall be documented that way.
>
> -Akhil
>

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Radu Nicolau]

Hi,


On 12/6/2017 7:30 AM, Anoob wrote:
> Hi Akhil, Radu,
>
> Please see inline.
>
> Thanks,
>
> Anoob
>
>
> On 11/24/2017 05:33 PM, Akhil Goyal wrote:
>> On 11/24/2017 5:29 PM, Radu Nicolau wrote:
>>>
>>>
>>> On 11/24/2017 11:34 AM, Akhil Goyal wrote:
>>>> Hi Radu,
>>>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>>>
>>>>>
>>>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Comment inline
>>>>>>>
>>>>>>>
>>>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>>>> Hi Anoob, Radu,
>>>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>>>> In case of inline protocol processed ingress traffic, the 
>>>>>>>>> packet may not
>>>>>>>>> have enough information to determine the security parameters 
>>>>>>>>> with which
>>>>>>>>> the packet was processed. In such cases, application could get 
>>>>>>>>> metadata
>>>>>>>>> from the packet which could be used to identify the security 
>>>>>>>>> parameters
>>>>>>>>> with which the packet was processed.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>>>> ---
>>>>>>>>> v3:
>>>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>>>>> instead of
>>>>>>>>>    uint64_t
>>>>>>>>>
>>>>>>>>> v2:
>>>>>>>>> * Replaced get_session and get_cookie APIs with 
>>>>>>>>> get_pkt_metadata API
>>>>>>>>>
>>>>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>>>>   lib/librte_security/rte_security.h        | 19 
>>>>>>>>> +++++++++++++++++++
>>>>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>>>> rte_security_ctx *instance,
>>>>>>>>>                              sess, m, params);
>>>>>>>>>   }
>>>>>>>>>   +void *
>>>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>>>> Can we rename pkt with m. Just to make it consistent with the 
>>>>>>>> set API.
>>>>>>>>> +{
>>>>>>>>> +    void *md = NULL;
>>>>>>>>> +
>>>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 
>>>>>>>>> NULL);
>>>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, 
>>>>>>>>> pkt, &md))
>>>>>>>>> +        return NULL;
>>>>>>>>> +
>>>>>>>>> +    return md;
>>>>>>>>> +}
>>>>>>>>
>>>>>>>> Pkt metadata should be set by user i.e. the application, and 
>>>>>>>> the driver need not be aware of the format and the values of 
>>>>>>>> the metadata.
>>>>>>>> So setting the metadata in the driver and getting it back from 
>>>>>>>> the driver does not look a good idea.
>>>>>>>>
>>>>>>>> Is it possible, that the application define the metadata on its 
>>>>>>>> own and set it in the library itself without the call to the 
>>>>>>>> driver ops.
>>>>>>> I'm not sure I understand here; even in our case (ixgbe) the 
>>>>>>> driver sets the metadata and it is aware of the format - that is 
>>>>>>> the whole idea. This is why we added the set_metadata API, to 
>>>>>>> allow the driver to inject extra information into the mbuf, 
>>>>>>> information that is driver specific and derived from the 
>>>>>>> security session, so it makes sense to also have a symmetric 
>>>>>>> get_metadata.
>>>>>>> Private data is the one that follows those rules, i.e. 
>>>>>>> application specific and driver transparent.
>>>>>>
>>>>>> As per my understanding of the user metadata, it should be in 
>>>>>> control of the application, and the application shall know the 
>>>>>> format of that. Setting in driver will disallow this.
>>>>>> Please let me know if my understanding is incorrect.
>>>>>>
>>>>>> If at all, some information is needed to be set on the basis of 
>>>>>> driver, then application can get that information from the driver 
>>>>>> and then set it in the packet metadata in its own way/format.
>>>>>
>>>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>>>> "device-specific defined metadata" and also takes a device 
>>>>> specific params pointer, so the symmetric function is to be 
>>>>> expected to work in the same way, i.e. return device specific 
>>>>> metadata associated with the security session and instance and 
>>>>> mbuf. How is this metadata stored is not specified in the security 
>>>>> API, so the PMD implementation have the flexibility.
> Is rte_security_get_pkt_metadata() expected to return a "device 
> specific" pointer? If that's the case, we would need another call 
> (something like, rte_security_get_userdata()) to get back the 
> userdata, right? Or is it fine, if the application assumes it will get 
> userdata (the one passed in conf while creating security session) with 
> rte_security_get_pkt_metadata()?
Yes, this will be my assumption, a "device specific" pointer (similar to 
the "void *params" parameter of the rte_security_set_pkt_metadata 
function), which will contain an arbitrary defined structure that will 
be decoded by calling a PMD defined function.
But I think Akhil has a different view on this.
>>>>>
>>>>
>>>> Yes it was defined that way and I did not noticed this one at the 
>>>> time of it's implementation.
>>>> Here, my point is that the application may be using mbuf udata for 
>>>> it's own functionality, it should not be modified in the driver.
>>>>
>>>> However, if we need to do this, then we may need to clarify in the 
>>>> documentation that for security, udata shall be set with the 
>>>> rte_security_set_pkt_metadata() and not otherwise.
>>> Indeed, we should update the doc stating that the set_metadata may 
>>> change the mbuf userdata field so the application should use only 
>>> private data if needed.
>>
>> Agreed, but it is dependent on which driver/mode(inline or 
>> lookaside), it will be used.
>> Lookaside may not need this API as of now. Other implementations may 
>> also don't require. So this shall be documented that way.
>>
>> -Akhil
>>
>

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Anoob]

Hi Akhil,

Can you confirm if you are fine with the approach explained inline.

Thanks,
Anoob

On 12/06/2017 03:13 PM, Radu Nicolau wrote:
> Hi,
>
>
> On 12/6/2017 7:30 AM, Anoob wrote:
>> Hi Akhil, Radu,
>>
>> Please see inline.
>>
>> Thanks,
>>
>> Anoob
>>
>>
>> On 11/24/2017 05:33 PM, Akhil Goyal wrote:
>>> On 11/24/2017 5:29 PM, Radu Nicolau wrote:
>>>>
>>>>
>>>> On 11/24/2017 11:34 AM, Akhil Goyal wrote:
>>>>> Hi Radu,
>>>>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>>>>
>>>>>>
>>>>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Comment inline
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>>>>> Hi Anoob, Radu,
>>>>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>>>>> In case of inline protocol processed ingress traffic, the 
>>>>>>>>>> packet may not
>>>>>>>>>> have enough information to determine the security parameters 
>>>>>>>>>> with which
>>>>>>>>>> the packet was processed. In such cases, application could 
>>>>>>>>>> get metadata
>>>>>>>>>> from the packet which could be used to identify the security 
>>>>>>>>>> parameters
>>>>>>>>>> with which the packet was processed.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>>>>> ---
>>>>>>>>>> v3:
>>>>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>>>>>> instead of
>>>>>>>>>>    uint64_t
>>>>>>>>>>
>>>>>>>>>> v2:
>>>>>>>>>> * Replaced get_session and get_cookie APIs with 
>>>>>>>>>> get_pkt_metadata API
>>>>>>>>>>
>>>>>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>>>>>   lib/librte_security/rte_security.h        | 19 
>>>>>>>>>> +++++++++++++++++++
>>>>>>>>>>   lib/librte_security/rte_security_driver.h | 16 
>>>>>>>>>> ++++++++++++++++
>>>>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>>>>> rte_security_ctx *instance,
>>>>>>>>>>                              sess, m, params);
>>>>>>>>>>   }
>>>>>>>>>>   +void *
>>>>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx 
>>>>>>>>>> *instance,
>>>>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>>>>> Can we rename pkt with m. Just to make it consistent with the 
>>>>>>>>> set API.
>>>>>>>>>> +{
>>>>>>>>>> +    void *md = NULL;
>>>>>>>>>> +
>>>>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 
>>>>>>>>>> NULL);
>>>>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, 
>>>>>>>>>> pkt, &md))
>>>>>>>>>> +        return NULL;
>>>>>>>>>> +
>>>>>>>>>> +    return md;
>>>>>>>>>> +}
>>>>>>>>>
>>>>>>>>> Pkt metadata should be set by user i.e. the application, and 
>>>>>>>>> the driver need not be aware of the format and the values of 
>>>>>>>>> the metadata.
>>>>>>>>> So setting the metadata in the driver and getting it back from 
>>>>>>>>> the driver does not look a good idea.
>>>>>>>>>
>>>>>>>>> Is it possible, that the application define the metadata on 
>>>>>>>>> its own and set it in the library itself without the call to 
>>>>>>>>> the driver ops.
>>>>>>>> I'm not sure I understand here; even in our case (ixgbe) the 
>>>>>>>> driver sets the metadata and it is aware of the format - that 
>>>>>>>> is the whole idea. This is why we added the set_metadata API, 
>>>>>>>> to allow the driver to inject extra information into the mbuf, 
>>>>>>>> information that is driver specific and derived from the 
>>>>>>>> security session, so it makes sense to also have a symmetric 
>>>>>>>> get_metadata.
>>>>>>>> Private data is the one that follows those rules, i.e. 
>>>>>>>> application specific and driver transparent.
>>>>>>>
>>>>>>> As per my understanding of the user metadata, it should be in 
>>>>>>> control of the application, and the application shall know the 
>>>>>>> format of that. Setting in driver will disallow this.
>>>>>>> Please let me know if my understanding is incorrect.
>>>>>>>
>>>>>>> If at all, some information is needed to be set on the basis of 
>>>>>>> driver, then application can get that information from the 
>>>>>>> driver and then set it in the packet metadata in its own 
>>>>>>> way/format.
>>>>>>
>>>>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>>>>> "device-specific defined metadata" and also takes a device 
>>>>>> specific params pointer, so the symmetric function is to be 
>>>>>> expected to work in the same way, i.e. return device specific 
>>>>>> metadata associated with the security session and instance and 
>>>>>> mbuf. How is this metadata stored is not specified in the 
>>>>>> security API, so the PMD implementation have the flexibility.
>> Is rte_security_get_pkt_metadata() expected to return a "device 
>> specific" pointer? If that's the case, we would need another call 
>> (something like, rte_security_get_userdata()) to get back the 
>> userdata, right? Or is it fine, if the application assumes it will 
>> get userdata (the one passed in conf while creating security session) 
>> with rte_security_get_pkt_metadata()?
> Yes, this will be my assumption, a "device specific" pointer (similar 
> to the "void *params" parameter of the rte_security_set_pkt_metadata 
> function), which will contain an arbitrary defined structure that will 
> be decoded by calling a PMD defined function.
> But I think Akhil has a different view on this.
>>>>>>
>>>>>
>>>>> Yes it was defined that way and I did not noticed this one at the 
>>>>> time of it's implementation.
>>>>> Here, my point is that the application may be using mbuf udata for 
>>>>> it's own functionality, it should not be modified in the driver.
>>>>>
>>>>> However, if we need to do this, then we may need to clarify in the 
>>>>> documentation that for security, udata shall be set with the 
>>>>> rte_security_set_pkt_metadata() and not otherwise.
>>>> Indeed, we should update the doc stating that the set_metadata may 
>>>> change the mbuf userdata field so the application should use only 
>>>> private data if needed.
>>>
>>> Agreed, but it is dependent on which driver/mode(inline or 
>>> lookaside), it will be used.
>>> Lookaside may not need this API as of now. Other implementations may 
>>> also don't require. So this shall be documented that way.
>>>
>>> -Akhil
>>>
>>
>

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Akhil Goyal]

Hi Anoob,

On 12/11/2017 12:51 PM, Anoob wrote:
> Hi Akhil,
> 
> Can you confirm if you are fine with the approach explained inline.
> 
> Thanks,
> Anoob
> 
> On 12/06/2017 03:13 PM, Radu Nicolau wrote:
>> Hi,
>>
>>
>> On 12/6/2017 7:30 AM, Anoob wrote:
>>> Hi Akhil, Radu,
>>>
>>> Please see inline.
>>>
>>> Thanks,
>>>
>>> Anoob
>>>
>>>
>>> On 11/24/2017 05:33 PM, Akhil Goyal wrote:
>>>> On 11/24/2017 5:29 PM, Radu Nicolau wrote:
>>>>>
>>>>>
>>>>> On 11/24/2017 11:34 AM, Akhil Goyal wrote:
>>>>>> Hi Radu,
>>>>>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>>>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Comment inline
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>>>>>> Hi Anoob, Radu,
>>>>>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>>>>>> In case of inline protocol processed ingress traffic, the 
>>>>>>>>>>> packet may not
>>>>>>>>>>> have enough information to determine the security parameters 
>>>>>>>>>>> with which
>>>>>>>>>>> the packet was processed. In such cases, application could 
>>>>>>>>>>> get metadata
>>>>>>>>>>> from the packet which could be used to identify the security 
>>>>>>>>>>> parameters
>>>>>>>>>>> with which the packet was processed.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>>>>>> ---
>>>>>>>>>>> v3:
>>>>>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>>>>>>> instead of
>>>>>>>>>>>    uint64_t
>>>>>>>>>>>
>>>>>>>>>>> v2:
>>>>>>>>>>> * Replaced get_session and get_cookie APIs with 
>>>>>>>>>>> get_pkt_metadata API
>>>>>>>>>>>
>>>>>>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>>>>>>   lib/librte_security/rte_security.h        | 19 
>>>>>>>>>>> +++++++++++++++++++
>>>>>>>>>>>   lib/librte_security/rte_security_driver.h | 16 
>>>>>>>>>>> ++++++++++++++++
>>>>>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>>>>>> rte_security_ctx *instance,
>>>>>>>>>>>                              sess, m, params);
>>>>>>>>>>>   }
>>>>>>>>>>>   +void *
>>>>>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx 
>>>>>>>>>>> *instance,
>>>>>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>>>>>> Can we rename pkt with m. Just to make it consistent with the 
>>>>>>>>>> set API.
>>>>>>>>>>> +{
>>>>>>>>>>> +    void *md = NULL;
>>>>>>>>>>> +
>>>>>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 
>>>>>>>>>>> NULL);
>>>>>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, 
>>>>>>>>>>> pkt, &md))
>>>>>>>>>>> +        return NULL;
>>>>>>>>>>> +
>>>>>>>>>>> +    return md;
>>>>>>>>>>> +}
>>>>>>>>>>
>>>>>>>>>> Pkt metadata should be set by user i.e. the application, and 
>>>>>>>>>> the driver need not be aware of the format and the values of 
>>>>>>>>>> the metadata.
>>>>>>>>>> So setting the metadata in the driver and getting it back from 
>>>>>>>>>> the driver does not look a good idea.
>>>>>>>>>>
>>>>>>>>>> Is it possible, that the application define the metadata on 
>>>>>>>>>> its own and set it in the library itself without the call to 
>>>>>>>>>> the driver ops.
>>>>>>>>> I'm not sure I understand here; even in our case (ixgbe) the 
>>>>>>>>> driver sets the metadata and it is aware of the format - that 
>>>>>>>>> is the whole idea. This is why we added the set_metadata API, 
>>>>>>>>> to allow the driver to inject extra information into the mbuf, 
>>>>>>>>> information that is driver specific and derived from the 
>>>>>>>>> security session, so it makes sense to also have a symmetric 
>>>>>>>>> get_metadata.
>>>>>>>>> Private data is the one that follows those rules, i.e. 
>>>>>>>>> application specific and driver transparent.
>>>>>>>>
>>>>>>>> As per my understanding of the user metadata, it should be in 
>>>>>>>> control of the application, and the application shall know the 
>>>>>>>> format of that. Setting in driver will disallow this.
>>>>>>>> Please let me know if my understanding is incorrect.
>>>>>>>>
>>>>>>>> If at all, some information is needed to be set on the basis of 
>>>>>>>> driver, then application can get that information from the 
>>>>>>>> driver and then set it in the packet metadata in its own 
>>>>>>>> way/format.
>>>>>>>
>>>>>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>>>>>> "device-specific defined metadata" and also takes a device 
>>>>>>> specific params pointer, so the symmetric function is to be 
>>>>>>> expected to work in the same way, i.e. return device specific 
>>>>>>> metadata associated with the security session and instance and 
>>>>>>> mbuf. How is this metadata stored is not specified in the 
>>>>>>> security API, so the PMD implementation have the flexibility.
>>> Is rte_security_get_pkt_metadata() expected to return a "device 
>>> specific" pointer? If that's the case, we would need another call 
>>> (something like, rte_security_get_userdata()) to get back the 
>>> userdata, right? Or is it fine, if the application assumes it will 
>>> get userdata (the one passed in conf while creating security session) 
>>> with rte_security_get_pkt_metadata()?
>> Yes, this will be my assumption, a "device specific" pointer (similar 
>> to the "void *params" parameter of the rte_security_set_pkt_metadata 
>> function), which will contain an arbitrary defined structure that will 
>> be decoded by calling a PMD defined function.
>> But I think Akhil has a different view on this.
I am ok with the approach, if we are adding this as a limitation of 
using udata in the documentation for inline cases.

The ideal approach should be such that driver should not be knowing the 
content of the udata. But, if we cannot do away with it, we can mention 
it in the documentation.

>>>>>>>
>>>>>>
>>>>>> Yes it was defined that way and I did not noticed this one at the 
>>>>>> time of it's implementation.
>>>>>> Here, my point is that the application may be using mbuf udata for 
>>>>>> it's own functionality, it should not be modified in the driver.
>>>>>>
>>>>>> However, if we need to do this, then we may need to clarify in the 
>>>>>> documentation that for security, udata shall be set with the 
>>>>>> rte_security_set_pkt_metadata() and not otherwise.
>>>>> Indeed, we should update the doc stating that the set_metadata may 
>>>>> change the mbuf userdata field so the application should use only 
>>>>> private data if needed.
>>>>
>>>> Agreed, but it is dependent on which driver/mode(inline or 
>>>> lookaside), it will be used.
>>>> Lookaside may not need this API as of now. Other implementations may 
>>>> also don't require. So this shall be documented that way.
>>>>
>>>> -Akhil
>>>>
>>>
>>
> 
> 

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Anoob Joseph]

Hi Akhil, Radu


On 12/12/2017 02:25 PM, Akhil Goyal wrote:
> Hi Anoob,
>
> On 12/11/2017 12:51 PM, Anoob wrote:
>> Hi Akhil,
>>
>> Can you confirm if you are fine with the approach explained inline.
>>
>> Thanks,
>> Anoob
>>
>> On 12/06/2017 03:13 PM, Radu Nicolau wrote:
>>> Hi,
>>>
>>>
>>> On 12/6/2017 7:30 AM, Anoob wrote:
>>>> Hi Akhil, Radu,
>>>>
>>>> Please see inline.
>>>>
>>>> Thanks,
>>>>
>>>> Anoob
>>>>
>>>>
>>>> On 11/24/2017 05:33 PM, Akhil Goyal wrote:
>>>>> On 11/24/2017 5:29 PM, Radu Nicolau wrote:
>>>>>>
>>>>>>
>>>>>> On 11/24/2017 11:34 AM, Akhil Goyal wrote:
>>>>>>> Hi Radu,
>>>>>>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>>>>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Comment inline
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>>>>>>> Hi Anoob, Radu,
>>>>>>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>>>>>>> In case of inline protocol processed ingress traffic, the 
>>>>>>>>>>>> packet may not
>>>>>>>>>>>> have enough information to determine the security 
>>>>>>>>>>>> parameters with which
>>>>>>>>>>>> the packet was processed. In such cases, application could 
>>>>>>>>>>>> get metadata
>>>>>>>>>>>> from the packet which could be used to identify the 
>>>>>>>>>>>> security parameters
>>>>>>>>>>>> with which the packet was processed.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> v3:
>>>>>>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>>>>>>> * The API(rte_security_get_pkt_metadata) would return void 
>>>>>>>>>>>> * instead of
>>>>>>>>>>>>    uint64_t
>>>>>>>>>>>>
>>>>>>>>>>>> v2:
>>>>>>>>>>>> * Replaced get_session and get_cookie APIs with 
>>>>>>>>>>>> get_pkt_metadata API
>>>>>>>>>>>>
>>>>>>>>>>>>   lib/librte_security/rte_security.c | 13 +++++++++++++
>>>>>>>>>>>>   lib/librte_security/rte_security.h | 19 +++++++++++++++++++
>>>>>>>>>>>>   lib/librte_security/rte_security_driver.h | 16 
>>>>>>>>>>>> ++++++++++++++++
>>>>>>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>>>>>>> rte_security_ctx *instance,
>>>>>>>>>>>>                              sess, m, params);
>>>>>>>>>>>>   }
>>>>>>>>>>>>   +void *
>>>>>>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx 
>>>>>>>>>>>> *instance,
>>>>>>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>>>>>>> Can we rename pkt with m. Just to make it consistent with 
>>>>>>>>>>> the set API.
>>>>>>>>>>>> +{
>>>>>>>>>>>> +    void *md = NULL;
>>>>>>>>>>>> +
>>>>>>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 
>>>>>>>>>>>> NULL);
>>>>>>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, 
>>>>>>>>>>>> pkt, &md))
>>>>>>>>>>>> +        return NULL;
>>>>>>>>>>>> +
>>>>>>>>>>>> +    return md;
>>>>>>>>>>>> +}
>>>>>>>>>>>
>>>>>>>>>>> Pkt metadata should be set by user i.e. the application, and 
>>>>>>>>>>> the driver need not be aware of the format and the values of 
>>>>>>>>>>> the metadata.
>>>>>>>>>>> So setting the metadata in the driver and getting it back 
>>>>>>>>>>> from the driver does not look a good idea.
>>>>>>>>>>>
>>>>>>>>>>> Is it possible, that the application define the metadata on 
>>>>>>>>>>> its own and set it in the library itself without the call to 
>>>>>>>>>>> the driver ops.
>>>>>>>>>> I'm not sure I understand here; even in our case (ixgbe) the 
>>>>>>>>>> driver sets the metadata and it is aware of the format - that 
>>>>>>>>>> is the whole idea. This is why we added the set_metadata API, 
>>>>>>>>>> to allow the driver to inject extra information into the 
>>>>>>>>>> mbuf, information that is driver specific and derived from 
>>>>>>>>>> the security session, so it makes sense to also have a 
>>>>>>>>>> symmetric get_metadata.
>>>>>>>>>> Private data is the one that follows those rules, i.e. 
>>>>>>>>>> application specific and driver transparent.
>>>>>>>>>
>>>>>>>>> As per my understanding of the user metadata, it should be in 
>>>>>>>>> control of the application, and the application shall know the 
>>>>>>>>> format of that. Setting in driver will disallow this.
>>>>>>>>> Please let me know if my understanding is incorrect.
>>>>>>>>>
>>>>>>>>> If at all, some information is needed to be set on the basis 
>>>>>>>>> of driver, then application can get that information from the 
>>>>>>>>> driver and then set it in the packet metadata in its own 
>>>>>>>>> way/format.
>>>>>>>>
>>>>>>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>>>>>>> "device-specific defined metadata" and also takes a device 
>>>>>>>> specific params pointer, so the symmetric function is to be 
>>>>>>>> expected to work in the same way, i.e. return device specific 
>>>>>>>> metadata associated with the security session and instance and 
>>>>>>>> mbuf. How is this metadata stored is not specified in the 
>>>>>>>> security API, so the PMD implementation have the flexibility.
>>>> Is rte_security_get_pkt_metadata() expected to return a "device 
>>>> specific" pointer? If that's the case, we would need another call 
>>>> (something like, rte_security_get_userdata()) to get back the 
>>>> userdata, right? Or is it fine, if the application assumes it will 
>>>> get userdata (the one passed in conf while creating security 
>>>> session) with rte_security_get_pkt_metadata()?
>>> Yes, this will be my assumption, a "device specific" pointer 
>>> (similar to the "void *params" parameter of the 
>>> rte_security_set_pkt_metadata function), which will contain an 
>>> arbitrary defined structure that will be decoded by calling a PMD 
>>> defined function.
>>> But I think Akhil has a different view on this.
> I am ok with the approach, if we are adding this as a limitation of 
> using udata in the documentation for inline cases.
>
> The ideal approach should be such that driver should not be knowing 
> the content of the udata. But, if we cannot do away with it, we can 
> mention it in the documentation.
Will document the limitation of udata64's usage. Since we are 
documenting that udata64 will have some device defined metadata, do we 
need another API call for getting the "metadata" 
(rte_security_get_pkt_metadata). The driver can set this metadata in 
udata64 field, and in ingress, the userdata could be obtained with a 
single API call (rte_security_get_userdata(*instance, udata64)).

The application will be aware that the udata64 in the mbuf will be the 
metadata from the receive side, and userdata can be retrieved only with 
that. If application need to use the udata64 field, it should save this 
rx metadata. Userdata can be obtained anytime by passing this metadata 
to the driver.

To summarize,
1) udata64 of the ingress traffic will be device-specific metadata 
(documentation change)
2) Pass this field to rte_security_get_userdata() to get back the 
application registered pointer.

Is this fine?

>
>>>>>>>>
>>>>>>>
>>>>>>> Yes it was defined that way and I did not noticed this one at 
>>>>>>> the time of it's implementation.
>>>>>>> Here, my point is that the application may be using mbuf udata 
>>>>>>> for it's own functionality, it should not be modified in the 
>>>>>>> driver.
>>>>>>>
>>>>>>> However, if we need to do this, then we may need to clarify in 
>>>>>>> the documentation that for security, udata shall be set with the 
>>>>>>> rte_security_set_pkt_metadata() and not otherwise.
>>>>>> Indeed, we should update the doc stating that the set_metadata 
>>>>>> may change the mbuf userdata field so the application should use 
>>>>>> only private data if needed.
>>>>>
>>>>> Agreed, but it is dependent on which driver/mode(inline or 
>>>>> lookaside), it will be used.
>>>>> Lookaside may not need this API as of now. Other implementations 
>>>>> may also don't require. So this shall be documented that way.
>>>>>
>>>>> -Akhil
>>>>>
>>>>
>>>
>>
>>
>

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Akhil Goyal]

On 12/12/2017 7:20 PM, Anoob Joseph wrote:
> Hi Akhil, Radu
> 
> 
> On 12/12/2017 02:25 PM, Akhil Goyal wrote:
>> Hi Anoob,
>>
>> On 12/11/2017 12:51 PM, Anoob wrote:
>>> Hi Akhil,
>>>
>>> Can you confirm if you are fine with the approach explained inline.
>>>
>>> Thanks,
>>> Anoob
>>>
>>> On 12/06/2017 03:13 PM, Radu Nicolau wrote:
>>>> Hi,
>>>>
>>>>
>>>> On 12/6/2017 7:30 AM, Anoob wrote:
>>>>> Hi Akhil, Radu,
>>>>>
>>>>> Please see inline.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Anoob
>>>>>
>>>>>
>>>>> On 11/24/2017 05:33 PM, Akhil Goyal wrote:
>>>>>> On 11/24/2017 5:29 PM, Radu Nicolau wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 11/24/2017 11:34 AM, Akhil Goyal wrote:
>>>>>>>> Hi Radu,
>>>>>>>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>>>>>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Comment inline
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>>>>>>>> Hi Anoob, Radu,
>>>>>>>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>>>>>>>> In case of inline protocol processed ingress traffic, the 
>>>>>>>>>>>>> packet may not
>>>>>>>>>>>>> have enough information to determine the security 
>>>>>>>>>>>>> parameters with which
>>>>>>>>>>>>> the packet was processed. In such cases, application could 
>>>>>>>>>>>>> get metadata
>>>>>>>>>>>>> from the packet which could be used to identify the 
>>>>>>>>>>>>> security parameters
>>>>>>>>>>>>> with which the packet was processed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> v3:
>>>>>>>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>>>>>>>> * The API(rte_security_get_pkt_metadata) would return void 
>>>>>>>>>>>>> * instead of
>>>>>>>>>>>>>    uint64_t
>>>>>>>>>>>>>
>>>>>>>>>>>>> v2:
>>>>>>>>>>>>> * Replaced get_session and get_cookie APIs with 
>>>>>>>>>>>>> get_pkt_metadata API
>>>>>>>>>>>>>
>>>>>>>>>>>>>   lib/librte_security/rte_security.c | 13 +++++++++++++
>>>>>>>>>>>>>   lib/librte_security/rte_security.h | 19 +++++++++++++++++++
>>>>>>>>>>>>>   lib/librte_security/rte_security_driver.h | 16 
>>>>>>>>>>>>> ++++++++++++++++
>>>>>>>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>>>>>>>> rte_security_ctx *instance,
>>>>>>>>>>>>>                              sess, m, params);
>>>>>>>>>>>>>   }
>>>>>>>>>>>>>   +void *
>>>>>>>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx 
>>>>>>>>>>>>> *instance,
>>>>>>>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>>>>>>>> Can we rename pkt with m. Just to make it consistent with 
>>>>>>>>>>>> the set API.
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> +    void *md = NULL;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, 
>>>>>>>>>>>>> NULL);
>>>>>>>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, 
>>>>>>>>>>>>> pkt, &md))
>>>>>>>>>>>>> +        return NULL;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +    return md;
>>>>>>>>>>>>> +}
>>>>>>>>>>>>
>>>>>>>>>>>> Pkt metadata should be set by user i.e. the application, and 
>>>>>>>>>>>> the driver need not be aware of the format and the values of 
>>>>>>>>>>>> the metadata.
>>>>>>>>>>>> So setting the metadata in the driver and getting it back 
>>>>>>>>>>>> from the driver does not look a good idea.
>>>>>>>>>>>>
>>>>>>>>>>>> Is it possible, that the application define the metadata on 
>>>>>>>>>>>> its own and set it in the library itself without the call to 
>>>>>>>>>>>> the driver ops.
>>>>>>>>>>> I'm not sure I understand here; even in our case (ixgbe) the 
>>>>>>>>>>> driver sets the metadata and it is aware of the format - that 
>>>>>>>>>>> is the whole idea. This is why we added the set_metadata API, 
>>>>>>>>>>> to allow the driver to inject extra information into the 
>>>>>>>>>>> mbuf, information that is driver specific and derived from 
>>>>>>>>>>> the security session, so it makes sense to also have a 
>>>>>>>>>>> symmetric get_metadata.
>>>>>>>>>>> Private data is the one that follows those rules, i.e. 
>>>>>>>>>>> application specific and driver transparent.
>>>>>>>>>>
>>>>>>>>>> As per my understanding of the user metadata, it should be in 
>>>>>>>>>> control of the application, and the application shall know the 
>>>>>>>>>> format of that. Setting in driver will disallow this.
>>>>>>>>>> Please let me know if my understanding is incorrect.
>>>>>>>>>>
>>>>>>>>>> If at all, some information is needed to be set on the basis 
>>>>>>>>>> of driver, then application can get that information from the 
>>>>>>>>>> driver and then set it in the packet metadata in its own 
>>>>>>>>>> way/format.
>>>>>>>>>
>>>>>>>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>>>>>>>> "device-specific defined metadata" and also takes a device 
>>>>>>>>> specific params pointer, so the symmetric function is to be 
>>>>>>>>> expected to work in the same way, i.e. return device specific 
>>>>>>>>> metadata associated with the security session and instance and 
>>>>>>>>> mbuf. How is this metadata stored is not specified in the 
>>>>>>>>> security API, so the PMD implementation have the flexibility.
>>>>> Is rte_security_get_pkt_metadata() expected to return a "device 
>>>>> specific" pointer? If that's the case, we would need another call 
>>>>> (something like, rte_security_get_userdata()) to get back the 
>>>>> userdata, right? Or is it fine, if the application assumes it will 
>>>>> get userdata (the one passed in conf while creating security 
>>>>> session) with rte_security_get_pkt_metadata()?
>>>> Yes, this will be my assumption, a "device specific" pointer 
>>>> (similar to the "void *params" parameter of the 
>>>> rte_security_set_pkt_metadata function), which will contain an 
>>>> arbitrary defined structure that will be decoded by calling a PMD 
>>>> defined function.
>>>> But I think Akhil has a different view on this.
>> I am ok with the approach, if we are adding this as a limitation of 
>> using udata in the documentation for inline cases.
>>
>> The ideal approach should be such that driver should not be knowing 
>> the content of the udata. But, if we cannot do away with it, we can 
>> mention it in the documentation.
> Will document the limitation of udata64's usage. Since we are 
> documenting that udata64 will have some device defined metadata, do we 
> need another API call for getting the "metadata" 
> (rte_security_get_pkt_metadata). The driver can set this metadata in 
> udata64 field, and in ingress, the userdata could be obtained with a 
> single API call (rte_security_get_userdata(*instance, udata64)).
> 
> The application will be aware that the udata64 in the mbuf will be the 
> metadata from the receive side, and userdata can be retrieved only with 
> that. If application need to use the udata64 field, it should save this 
> rx metadata. Userdata can be obtained anytime by passing this metadata 
> to the driver.
> 
> To summarize,
> 1) udata64 of the ingress traffic will be device-specific metadata 
> (documentation change)
> 2) Pass this field to rte_security_get_userdata() to get back the 
> application registered pointer.
> 
> Is this fine?
It looks ok as of now.
> 
>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes it was defined that way and I did not noticed this one at 
>>>>>>>> the time of it's implementation.
>>>>>>>> Here, my point is that the application may be using mbuf udata 
>>>>>>>> for it's own functionality, it should not be modified in the 
>>>>>>>> driver.
>>>>>>>>
>>>>>>>> However, if we need to do this, then we may need to clarify in 
>>>>>>>> the documentation that for security, udata shall be set with the 
>>>>>>>> rte_security_set_pkt_metadata() and not otherwise.
>>>>>>> Indeed, we should update the doc stating that the set_metadata 
>>>>>>> may change the mbuf userdata field so the application should use 
>>>>>>> only private data if needed.
>>>>>>
>>>>>> Agreed, but it is dependent on which driver/mode(inline or 
>>>>>> lookaside), it will be used.
>>>>>> Lookaside may not need this API as of now. Other implementations 
>>>>>> may also don't require. So this shall be documented that way.
>>>>>>
>>>>>> -Akhil
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Anoob]

Hi Akhil, Radu

PLease see inline.

Thanks,

Anoob


On 11/24/2017 05:04 PM, Akhil Goyal wrote:
> Hi Radu,
> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>
>>
>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>> Hi,
>>>>
>>>> Comment inline
>>>>
>>>>
>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>> Hi Anoob, Radu,
>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>> In case of inline protocol processed ingress traffic, the packet 
>>>>>> may not
>>>>>> have enough information to determine the security parameters with 
>>>>>> which
>>>>>> the packet was processed. In such cases, application could get 
>>>>>> metadata
>>>>>> from the packet which could be used to identify the security 
>>>>>> parameters
>>>>>> with which the packet was processed.
>>>>>>
>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>> ---
>>>>>> v3:
>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>> instead of
>>>>>>    uint64_t
>>>>>>
>>>>>> v2:
>>>>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>>>>>
>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>>>   3 files changed, 48 insertions(+)
>>>>>>
>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>> b/lib/librte_security/rte_security.c
>>>>>> index 1227fca..a1d78b6 100644
>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>> rte_security_ctx *instance,
>>>>>>                              sess, m, params);
>>>>>>   }
>>>>>>   +void *
>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>>> +                  struct rte_mbuf *pkt)
>>>>> Can we rename pkt with m. Just to make it consistent with the set 
>>>>> API.
>>>>>> +{
>>>>>> +    void *md = NULL;
>>>>>> +
>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, 
>>>>>> &md))
>>>>>> +        return NULL;
>>>>>> +
>>>>>> +    return md;
>>>>>> +}
>>>>>
>>>>> Pkt metadata should be set by user i.e. the application, and the 
>>>>> driver need not be aware of the format and the values of the 
>>>>> metadata.
>>>>> So setting the metadata in the driver and getting it back from the 
>>>>> driver does not look a good idea.
>>>>>
>>>>> Is it possible, that the application define the metadata on its 
>>>>> own and set it in the library itself without the call to the 
>>>>> driver ops.
My first patch was along those lines. Can you take a look at that and 
give your comments?

If we add this metadata in rte_security_session, we can achieve the 
above behavior without driver maintaining the metadata. But from the 
packet, application will have to first get the security session. And 
then application can get the metadata by calling "get metadata" with 
rte_security_session as the argument. So we will need a "get_session" 
API(which reaches the driver) and then do "get_app_metadata".
>>>> I'm not sure I understand here; even in our case (ixgbe) the driver 
>>>> sets the metadata and it is aware of the format - that is the whole 
>>>> idea. This is why we added the set_metadata API, to allow the 
>>>> driver to inject extra information into the mbuf, information that 
>>>> is driver specific and derived from the security session, so it 
>>>> makes sense to also have a symmetric get_metadata.
>>>> Private data is the one that follows those rules, i.e. application 
>>>> specific and driver transparent.
>>>
>>> As per my understanding of the user metadata, it should be in 
>>> control of the application, and the application shall know the 
>>> format of that. Setting in driver will disallow this.
>>> Please let me know if my understanding is incorrect.
Your understanding is correct. That' the requirement.
>>>
>>> If at all, some information is needed to be set on the basis of 
>>> driver, then application can get that information from the driver 
>>> and then set it in the packet metadata in its own way/format.
>>
>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>> "device-specific defined metadata" and also takes a device specific 
>> params pointer, so the symmetric function is to be expected to work 
>> in the same way, i.e. return device specific metadata associated with 
>> the security session and instance and mbuf. How is this metadata 
>> stored is not specified in the security API, so the PMD 
>> implementation have the flexibility.
The requirement in this case isn't exactly parallel to 
"set_pkt_metadata". May be we can drop making it symmetric?
>>
>
> Yes it was defined that way and I did not noticed this one at the time 
> of it's implementation.
> Here, my point is that the application may be using mbuf udata for 
> it's own functionality, it should not be modified in the driver.
>
> However, if we need to do this, then we may need to clarify in the 
> documentation that for security, udata shall be set with the 
> rte_security_set_pkt_metadata() and not otherwise.
>
> -Akhil

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Anoob]

Hi Akhil, Radu,

Is there any update on how we should approach this?

Thanks,

Anoob


On 11/24/2017 05:52 PM, Anoob wrote:
> Hi Akhil, Radu
>
> Please see inline.
>
> Thanks,
>
> Anoob
>
>
> On 11/24/2017 05:04 PM, Akhil Goyal wrote:
>> Hi Radu,
>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>
>>>
>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>> Hi,
>>>>>
>>>>> Comment inline
>>>>>
>>>>>
>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>> Hi Anoob, Radu,
>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>> In case of inline protocol processed ingress traffic, the packet 
>>>>>>> may not
>>>>>>> have enough information to determine the security parameters 
>>>>>>> with which
>>>>>>> the packet was processed. In such cases, application could get 
>>>>>>> metadata
>>>>>>> from the packet which could be used to identify the security 
>>>>>>> parameters
>>>>>>> with which the packet was processed.
>>>>>>>
>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>> ---
>>>>>>> v3:
>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>>> instead of
>>>>>>>    uint64_t
>>>>>>>
>>>>>>> v2:
>>>>>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata 
>>>>>>> API
>>>>>>>
>>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>>   lib/librte_security/rte_security.h        | 19 
>>>>>>> +++++++++++++++++++
>>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>
>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>> rte_security_ctx *instance,
>>>>>>>                              sess, m, params);
>>>>>>>   }
>>>>>>>   +void *
>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>> Can we rename pkt with m. Just to make it consistent with the set 
>>>>>> API.
>>>>>>> +{
>>>>>>> +    void *md = NULL;
>>>>>>> +
>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, 
>>>>>>> &md))
>>>>>>> +        return NULL;
>>>>>>> +
>>>>>>> +    return md;
>>>>>>> +}
>>>>>>
>>>>>> Pkt metadata should be set by user i.e. the application, and the 
>>>>>> driver need not be aware of the format and the values of the 
>>>>>> metadata.
>>>>>> So setting the metadata in the driver and getting it back from 
>>>>>> the driver does not look a good idea.
>>>>>>
>>>>>> Is it possible, that the application define the metadata on its 
>>>>>> own and set it in the library itself without the call to the 
>>>>>> driver ops.
> My first patch was along those lines. Can you take a look at that and 
> give your comments?
>
> If we add this metadata in rte_security_session, we can achieve the 
> above behavior without driver maintaining the metadata. But from the 
> packet, application will have to first get the security session. And 
> then application can get the metadata by calling "get metadata" with 
> rte_security_session as the argument. So we will need a "get_session" 
> API(which reaches the driver) and then do "get_app_metadata".
>>>>> I'm not sure I understand here; even in our case (ixgbe) the 
>>>>> driver sets the metadata and it is aware of the format - that is 
>>>>> the whole idea. This is why we added the set_metadata API, to 
>>>>> allow the driver to inject extra information into the mbuf, 
>>>>> information that is driver specific and derived from the security 
>>>>> session, so it makes sense to also have a symmetric get_metadata.
>>>>> Private data is the one that follows those rules, i.e. application 
>>>>> specific and driver transparent.
>>>>
>>>> As per my understanding of the user metadata, it should be in 
>>>> control of the application, and the application shall know the 
>>>> format of that. Setting in driver will disallow this.
>>>> Please let me know if my understanding is incorrect.
> Your understanding is correct. That' the requirement.
>>>>
>>>> If at all, some information is needed to be set on the basis of 
>>>> driver, then application can get that information from the driver 
>>>> and then set it in the packet metadata in its own way/format.
>>>
>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>> "device-specific defined metadata" and also takes a device specific 
>>> params pointer, so the symmetric function is to be expected to work 
>>> in the same way, i.e. return device specific metadata associated 
>>> with the security session and instance and mbuf. How is this 
>>> metadata stored is not specified in the security API, so the PMD 
>>> implementation have the flexibility.
> The requirement in this case isn't exactly parallel to 
> "set_pkt_metadata". May be we can drop making it symmetric?
>>>
>>
>> Yes it was defined that way and I did not noticed this one at the 
>> time of it's implementation.
>> Here, my point is that the application may be using mbuf udata for 
>> it's own functionality, it should not be modified in the driver.
>>
>> However, if we need to do this, then we may need to clarify in the 
>> documentation that for security, udata shall be set with the 
>> rte_security_set_pkt_metadata() and not otherwise.
>>
>> -Akhil
>

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Akhil Goyal]

Hi Anoob,

On 11/24/2017 5:52 PM, Anoob wrote:
> Hi Akhil, Radu
> 
> PLease see inline.
> 
> Thanks,
> 
> Anoob
> 
> 
> On 11/24/2017 05:04 PM, Akhil Goyal wrote:
>> Hi Radu,
>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>
>>>
>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>> Hi,
>>>>>
>>>>> Comment inline
>>>>>
>>>>>
>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>> Hi Anoob, Radu,
>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>> In case of inline protocol processed ingress traffic, the packet 
>>>>>>> may not
>>>>>>> have enough information to determine the security parameters with 
>>>>>>> which
>>>>>>> the packet was processed. In such cases, application could get 
>>>>>>> metadata
>>>>>>> from the packet which could be used to identify the security 
>>>>>>> parameters
>>>>>>> with which the packet was processed.
>>>>>>>
>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>> ---
>>>>>>> v3:
>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>>> instead of
>>>>>>>    uint64_t
>>>>>>>
>>>>>>> v2:
>>>>>>> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
>>>>>>>
>>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>>   lib/librte_security/rte_security.h        | 19 +++++++++++++++++++
>>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>
>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>> rte_security_ctx *instance,
>>>>>>>                              sess, m, params);
>>>>>>>   }
>>>>>>>   +void *
>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>> Can we rename pkt with m. Just to make it consistent with the set 
>>>>>> API.
>>>>>>> +{
>>>>>>> +    void *md = NULL;
>>>>>>> +
>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, 
>>>>>>> &md))
>>>>>>> +        return NULL;
>>>>>>> +
>>>>>>> +    return md;
>>>>>>> +}
>>>>>>
>>>>>> Pkt metadata should be set by user i.e. the application, and the 
>>>>>> driver need not be aware of the format and the values of the 
>>>>>> metadata.
>>>>>> So setting the metadata in the driver and getting it back from the 
>>>>>> driver does not look a good idea.
>>>>>>
>>>>>> Is it possible, that the application define the metadata on its 
>>>>>> own and set it in the library itself without the call to the 
>>>>>> driver ops.
> My first patch was along those lines. Can you take a look at that and 
> give your comments?
> 
> If we add this metadata in rte_security_session, we can achieve the 
> above behavior without driver maintaining the metadata. But from the 
> packet, application will have to first get the security session. And 
> then application can get the metadata by calling "get metadata" with 
> rte_security_session as the argument. So we will need a "get_session" 
> API(which reaches the driver) and then do "get_app_metadata".
In that case also, the application cannot set metadata independently.
It will rather become more complex.
It is better that we document this properly in the documentation as 
discussed in my/Radu's previous mail.
>>>>> I'm not sure I understand here; even in our case (ixgbe) the driver 
>>>>> sets the metadata and it is aware of the format - that is the whole 
>>>>> idea. This is why we added the set_metadata API, to allow the 
>>>>> driver to inject extra information into the mbuf, information that 
>>>>> is driver specific and derived from the security session, so it 
>>>>> makes sense to also have a symmetric get_metadata.
>>>>> Private data is the one that follows those rules, i.e. application 
>>>>> specific and driver transparent.
>>>>
>>>> As per my understanding of the user metadata, it should be in 
>>>> control of the application, and the application shall know the 
>>>> format of that. Setting in driver will disallow this.
>>>> Please let me know if my understanding is incorrect.
> Your understanding is correct. That' the requirement.
>>>>
>>>> If at all, some information is needed to be set on the basis of 
>>>> driver, then application can get that information from the driver 
>>>> and then set it in the packet metadata in its own way/format.
>>>
>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>> "device-specific defined metadata" and also takes a device specific 
>>> params pointer, so the symmetric function is to be expected to work 
>>> in the same way, i.e. return device specific metadata associated with 
>>> the security session and instance and mbuf. How is this metadata 
>>> stored is not specified in the security API, so the PMD 
>>> implementation have the flexibility.
> The requirement in this case isn't exactly parallel to 
> "set_pkt_metadata". May be we can drop making it symmetric?
>>>
>>
>> Yes it was defined that way and I did not noticed this one at the time 
>> of it's implementation.
>> Here, my point is that the application may be using mbuf udata for 
>> it's own functionality, it should not be modified in the driver.
>>
>> However, if we need to do this, then we may need to clarify in the 
>> documentation that for security, udata shall be set with the 
>> rte_security_set_pkt_metadata() and not otherwise.
>>
>> -Akhil
> 
> 

Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata

[Anoob]

Hi Akhil,

See inline.

Thanks,
Anoob

On 12/04/2017 02:58 PM, Akhil Goyal wrote:
> Hi Anoob,
>
> On 11/24/2017 5:52 PM, Anoob wrote:
>> Hi Akhil, Radu
>>
>> PLease see inline.
>>
>> Thanks,
>>
>> Anoob
>>
>>
>> On 11/24/2017 05:04 PM, Akhil Goyal wrote:
>>> Hi Radu,
>>> On 11/24/2017 4:47 PM, Radu Nicolau wrote:
>>>>
>>>>
>>>> On 11/24/2017 10:55 AM, Akhil Goyal wrote:
>>>>> On 11/24/2017 3:09 PM, Radu Nicolau wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Comment inline
>>>>>>
>>>>>>
>>>>>> On 11/24/2017 8:50 AM, Akhil Goyal wrote:
>>>>>>> Hi Anoob, Radu,
>>>>>>> On 11/23/2017 4:49 PM, Anoob Joseph wrote:
>>>>>>>> In case of inline protocol processed ingress traffic, the 
>>>>>>>> packet may not
>>>>>>>> have enough information to determine the security parameters 
>>>>>>>> with which
>>>>>>>> the packet was processed. In such cases, application could get 
>>>>>>>> metadata
>>>>>>>> from the packet which could be used to identify the security 
>>>>>>>> parameters
>>>>>>>> with which the packet was processed.
>>>>>>>>
>>>>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>>>>> ---
>>>>>>>> v3:
>>>>>>>> * Replaced 64 bit metadata in conf with (void *)userdata
>>>>>>>> * The API(rte_security_get_pkt_metadata) would return void * 
>>>>>>>> instead of
>>>>>>>>    uint64_t
>>>>>>>>
>>>>>>>> v2:
>>>>>>>> * Replaced get_session and get_cookie APIs with 
>>>>>>>> get_pkt_metadata API
>>>>>>>>
>>>>>>>>   lib/librte_security/rte_security.c        | 13 +++++++++++++
>>>>>>>>   lib/librte_security/rte_security.h        | 19 
>>>>>>>> +++++++++++++++++++
>>>>>>>>   lib/librte_security/rte_security_driver.h | 16 ++++++++++++++++
>>>>>>>>   3 files changed, 48 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/lib/librte_security/rte_security.c 
>>>>>>>> b/lib/librte_security/rte_security.c
>>>>>>>> index 1227fca..a1d78b6 100644
>>>>>>>> --- a/lib/librte_security/rte_security.c
>>>>>>>> +++ b/lib/librte_security/rte_security.c
>>>>>>>> @@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct 
>>>>>>>> rte_security_ctx *instance,
>>>>>>>>                              sess, m, params);
>>>>>>>>   }
>>>>>>>>   +void *
>>>>>>>> +rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>>>>>> +                  struct rte_mbuf *pkt)
>>>>>>> Can we rename pkt with m. Just to make it consistent with the 
>>>>>>> set API.
>>>>>>>> +{
>>>>>>>> +    void *md = NULL;
>>>>>>>> +
>>>>>>>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata, NULL);
>>>>>>>> +    if (instance->ops->get_pkt_metadata(instance->device, pkt, 
>>>>>>>> &md))
>>>>>>>> +        return NULL;
>>>>>>>> +
>>>>>>>> +    return md;
>>>>>>>> +}
>>>>>>>
>>>>>>> Pkt metadata should be set by user i.e. the application, and the 
>>>>>>> driver need not be aware of the format and the values of the 
>>>>>>> metadata.
>>>>>>> So setting the metadata in the driver and getting it back from 
>>>>>>> the driver does not look a good idea.
>>>>>>>
>>>>>>> Is it possible, that the application define the metadata on its 
>>>>>>> own and set it in the library itself without the call to the 
>>>>>>> driver ops.
>> My first patch was along those lines. Can you take a look at that and 
>> give your comments?
>>
>> If we add this metadata in rte_security_session, we can achieve the 
>> above behavior without driver maintaining the metadata. But from the 
>> packet, application will have to first get the security session. And 
>> then application can get the metadata by calling "get metadata" with 
>> rte_security_session as the argument. So we will need a "get_session" 
>> API(which reaches the driver) and then do "get_app_metadata".
> In that case also, the application cannot set metadata independently.
> It will rather become more complex.
> It is better that we document this properly in the documentation as 
> discussed in my/Radu's previous mail.
I'll update the documentation with this behavior and will send a new patch.
>>>>>> I'm not sure I understand here; even in our case (ixgbe) the 
>>>>>> driver sets the metadata and it is aware of the format - that is 
>>>>>> the whole idea. This is why we added the set_metadata API, to 
>>>>>> allow the driver to inject extra information into the mbuf, 
>>>>>> information that is driver specific and derived from the security 
>>>>>> session, so it makes sense to also have a symmetric get_metadata.
>>>>>> Private data is the one that follows those rules, i.e. 
>>>>>> application specific and driver transparent.
>>>>>
>>>>> As per my understanding of the user metadata, it should be in 
>>>>> control of the application, and the application shall know the 
>>>>> format of that. Setting in driver will disallow this.
>>>>> Please let me know if my understanding is incorrect.
>> Your understanding is correct. That' the requirement.
>>>>>
>>>>> If at all, some information is needed to be set on the basis of 
>>>>> driver, then application can get that information from the driver 
>>>>> and then set it in the packet metadata in its own way/format.
>>>>
>>>> The rte_security_set_pkt_metadata() doc defines the metadata as 
>>>> "device-specific defined metadata" and also takes a device specific 
>>>> params pointer, so the symmetric function is to be expected to work 
>>>> in the same way, i.e. return device specific metadata associated 
>>>> with the security session and instance and mbuf. How is this 
>>>> metadata stored is not specified in the security API, so the PMD 
>>>> implementation have the flexibility.
>> The requirement in this case isn't exactly parallel to 
>> "set_pkt_metadata". May be we can drop making it symmetric?
>>>>
>>>
>>> Yes it was defined that way and I did not noticed this one at the 
>>> time of it's implementation.
>>> Here, my point is that the application may be using mbuf udata for 
>>> it's own functionality, it should not be modified in the driver.
>>>
>>> However, if we need to do this, then we may need to clarify in the 
>>> documentation that for security, udata shall be set with the 
>>> rte_security_set_pkt_metadata() and not otherwise.
>>>
>>> -Akhil
>>
>>
>

[dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add support for inline protocol

[Anoob Joseph]

Adding support for inline protocol processing

In ingress side, application will receive regular IP packets, without
any IPsec related info. Application will do a selector check (SP-SA
check) by making use of the metadata from the packet.

In egress side, the plain packet would be submitted to the driver. The
packet will have optional metadata, which could be used to identify the
security session associated with the packet.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v3:
* Using (void *)userdata instead of 64 bit metadata in conf
* Changes parallel to the change in API

v2:
* Using get_pkt_metadata API instead of get_session & get_cookie APIs

 examples/ipsec-secgw/esp.c         |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c |  40 +++++++++++-
 examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
 3 files changed, 145 insertions(+), 22 deletions(-)

diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index c3efe52..561f873 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
 	RTE_ASSERT(sa != NULL);
 	RTE_ASSERT(cop != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
 			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
 				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
@@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
 	RTE_ASSERT(m != NULL);
 	RTE_ASSERT(sa != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
 	} else {
 		RTE_ASSERT(cop != NULL);
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index c98454a..c79e1c2 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -265,6 +265,38 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
 		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
 		rte_pktmbuf_free(pkt);
 	}
+
+	/* Check if the packet has been processed inline. For inline protocol
+	 * processed packets, metadata from the packet need to be obtained.
+	 * This metadata will be the application registered "userdata" of the
+	 * security session which processed the packet.
+	 */
+
+	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
+		struct ipsec_sa *sa;
+		struct ipsec_mbuf_metadata *priv;
+		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
+						rte_eth_dev_get_sec_ctx(
+						pkt->port);
+
+		/* Get metadata from the packet. This will return application
+		 * registered userdata of the security session which processed
+		 * the packet. Here, the userdata registered is the SA pointer.
+		 */
+		sa = (struct ipsec_sa *)rte_security_get_pkt_metadata(ctx, pkt);
+
+		if (sa == NULL) {
+			/* userdata could not be retrieved */
+			return;
+		}
+
+		/* Save SA as priv member in mbuf. This will be used in the
+		 * IPsec selector(SP-SA) check.
+		 */
+
+		priv = get_priv(pkt);
+		priv->sa = sa;
+	}
 }
 
 static inline void
@@ -401,11 +433,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
 			ip->pkts[j++] = m;
 			continue;
 		}
-		if (res & DISCARD || i < lim) {
+		if (res & DISCARD) {
 			rte_pktmbuf_free(m);
 			continue;
 		}
+
 		/* Only check SPI match for processed IPSec packets */
+		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
+			rte_pktmbuf_free(m);
+			continue;
+		}
+
 		sa_idx = ip->res[i] & PROTECT_MASK;
 		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
 			rte_pktmbuf_free(m);
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 70ed227..3ad3692 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -46,6 +46,27 @@
 #include "ipsec.h"
 #include "esp.h"
 
+static inline void
+set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
+{
+	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
+		struct rte_security_ipsec_tunnel_param *tunnel =
+				&ipsec->tunnel;
+		if (sa->flags == IP4_TUNNEL) {
+			tunnel->type =
+				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
+			tunnel->ipv4.ttl = IPDEFTTL;
+
+			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
+				(uint8_t *)&sa->src.ip.ip4, 4);
+
+			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
+				(uint8_t *)&sa->dst.ip.ip4, 4);
+		}
+		/* TODO support for Transport and IPV6 tunnel */
+	}
+}
+
 static inline int
 create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 {
@@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
 					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
 			} },
-			.crypto_xform = sa->xforms
+			.crypto_xform = sa->xforms,
+			.userdata = NULL,
 
 		};
 
@@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 							rte_cryptodev_get_sec_ctx(
 							ipsec_ctx->tbl[cdev_id_qp].id);
 
-			if (sess_conf.ipsec.mode ==
-					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
-				struct rte_security_ipsec_tunnel_param *tunnel =
-						&sess_conf.ipsec.tunnel;
-				if (sa->flags == IP4_TUNNEL) {
-					tunnel->type =
-						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
-					tunnel->ipv4.ttl = IPDEFTTL;
-
-					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
-						(uint8_t *)&sa->src.ip.ip4, 4);
-
-					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
-						(uint8_t *)&sa->dst.ip.ip4, 4);
-				}
-				/* TODO support for Transport and IPV6 tunnel */
-			}
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
 
 			sa->sec_session = rte_security_session_create(ctx,
 					&sess_conf, ipsec_ctx->session_pool);
@@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					err.message);
 				return -1;
 			}
+		} else if (sa->type ==
+				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
+			struct rte_security_ctx *ctx =
+					(struct rte_security_ctx *)
+					rte_eth_dev_get_sec_ctx(sa->portid);
+			const struct rte_security_capability *sec_cap;
+
+			if (ctx == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"Ethernet device doesn't have security features registered\n");
+				return -1;
+			}
+
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
+
+			/* Save SA as userdata for the security session. When
+			 * the packet is received, this userdata will be
+			 * retrieved as the metadata from the packet.
+			 *
+			 * This is required only for inbound SAs.
+			 */
+
+			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
+				sess_conf.userdata = (void *) sa;
+
+			sa->sec_session = rte_security_session_create(ctx,
+					&sess_conf, ipsec_ctx->session_pool);
+			if (sa->sec_session == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"SEC Session init failed: err: %d\n", ret);
+				return -1;
+			}
+
+			sec_cap = rte_security_capabilities_get(ctx);
+
+			if (sec_cap == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"No capabilities registered\n");
+				return -1;
+			}
+
+			/* iterate until ESP tunnel*/
+			while (sec_cap->action !=
+					RTE_SECURITY_ACTION_TYPE_NONE) {
+
+				if (sec_cap->action == sa->type &&
+				    sec_cap->protocol ==
+					RTE_SECURITY_PROTOCOL_IPSEC &&
+				    sec_cap->ipsec.mode ==
+					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
+				    sec_cap->ipsec.direction == sa->direction)
+					break;
+				sec_cap++;
+			}
+
+			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
+				RTE_LOG(ERR, IPSEC,
+				"No suitable security capability found\n");
+				return -1;
+			}
+
+			sa->ol_flags = sec_cap->ol_flags;
+			sa->security_ctx = ctx;
 		}
 	} else {
 		sa->crypto_session = rte_cryptodev_sym_session_create(
@@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
 			}
 			break;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-			break;
+			if ((unlikely(sa->sec_session == NULL)) &&
+					create_session(ipsec_ctx, sa)) {
+				rte_pktmbuf_free(pkts[i]);
+				continue;
+			}
+
+			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
+			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
+			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
+				rte_security_set_pkt_metadata(
+						sa->security_ctx,
+						sa->sec_session, pkts[i], NULL);
+			continue;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
 			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
 			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add support for inline protocol

[Radu Nicolau]

On 11/23/2017 11:19 AM, Anoob Joseph wrote:
> Adding support for inline protocol processing
>
> In ingress side, application will receive regular IP packets, without
> any IPsec related info. Application will do a selector check (SP-SA
> check) by making use of the metadata from the packet.
>
> In egress side, the plain packet would be submitted to the driver. The
> packet will have optional metadata, which could be used to identify the
> security session associated with the packet.
>
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
>
Acked-by: Radu Nicolau <radu.nicolau@intel.com>

[dpdk-dev] [PATCH v4 0/2] add inline protocol support

[Anoob Joseph]

The series adds inline protocol support in DPDK.

First patch introduces changes in lib to enable applications to save a
(void *) pointer as "userdata" in security session. For inline processed
packets, applications would use the metadata field in the mbuf
(rte_mbuf.udata64) to retrieve the userdata registered for the security
session which processed the packet. The metadata would be device
specific.

This is primarily required for inline protocol processed ingress
packets. For such packets, the packet may not have enough information to
identify the security parameters with which the packet was processed.
Application can register what it needs to identify the required
parameter. The userdata will be set while creating the security
session.

Second patch adds support for inline protocol in ipsec-secgw
application

Anoob Joseph (2):
  lib/security: add support for get metadata
  examples/ipsec-secgw: add support for inline protocol

 doc/guides/prog_guide/rte_security.rst       |  22 ++++-
 examples/ipsec-secgw/esp.c                   |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c           |  42 +++++++++-
 examples/ipsec-secgw/ipsec.c                 | 121 ++++++++++++++++++++++-----
 lib/librte_security/rte_security.c           |  12 +++
 lib/librte_security/rte_security.h           |  20 +++++
 lib/librte_security/rte_security_driver.h    |  18 ++++
 lib/librte_security/rte_security_version.map |   1 +
 8 files changed, 219 insertions(+), 23 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH v4 1/2] lib/security: add support for get userdata

[Anoob Joseph]

In case of inline protocol processed ingress traffic, the packet may not
have enough information to determine the security parameters with which
the packet was processed. In such cases, application could get metadata
from the packet which could be used to identify the security parameters
with which the packet was processed.

Application could register "userdata" with the security session, and
this could be retrieved from the metadata of inline processed packets.
The metadata returned by "rte_security_get_pkt_metadata()" will be
device specific. Also the driver is expected to return the application
registered "userdata" as is, without any modifications.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v4:
* Documented the usage of rte_mbuf.udata64 field by security library
* Removed (rte_security_get_pkt_metadata() API as the udata64 field itself
  will have device-specific metadata, and could be directly used

v3:
* Replaced 64 bit metadata in conf with (void *)userdata
* The API(rte_security_get_pkt_metadata) would return void * instead of
  uint64_t

v2:
* Replaced get_session and get_cookie APIs with get_pkt_metadata API

 doc/guides/prog_guide/rte_security.rst       | 22 +++++++++++++++++++++-
 lib/librte_security/rte_security.c           | 12 ++++++++++++
 lib/librte_security/rte_security.h           | 20 ++++++++++++++++++++
 lib/librte_security/rte_security_driver.h    | 18 ++++++++++++++++++
 lib/librte_security/rte_security_version.map |  1 +
 5 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index 71be036..6768ebe 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -148,7 +148,9 @@ packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
 ESP/AH headers will be removed from the packet and the received packet
 will contains the decrypted packet only. The driver Rx path checks the
 descriptors and based on the crypto status sets additional flags in
-``rte_mbuf.ol_flags`` field.
+``rte_mbuf.ol_flags`` field. The driver would also set device-specific
+metadata in ``rte_mbuf.udata64`` field. This will allow the application
+to identify the security processing done on the packet.
 
 .. note::
 
@@ -421,6 +423,22 @@ For Inline Crypto and Inline protocol offload, device specific defined metadata
 updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
 ``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
 
+For inline protocol offloaded ingress traffic, the application can register a
+pointer, ``userdata`` , in the security session. When the packet is received,
+``rte_security_get_userdata()`` would return the userdata registered for the
+security session which processed the packet.
+
+.. note::
+
+    In case of inline processed packets, ``rte_mbuf.udata64`` field would be
+    used by the driver to relay information on the security processing
+    associated with the packet. In ingress, the driver would set this in Rx
+    path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
+    similar operation. The application is expected not to modify the field
+    when it has relevant info. For ingress, this device-specific 64 bit value
+    is required to derive other information (like userdata), required for
+    identifying the security processing done on the packet.
+
 Security session configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -440,6 +458,8 @@ Security Session configuration structure is defined as ``rte_security_session_co
         /**< Configuration parameters for security session */
         struct rte_crypto_sym_xform *crypto_xform;
         /**< Security Session Crypto Transformations */
+        void *userdata;
+        /**< Application specific userdata to be saved with session */
     };
 
 The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
index 1227fca..5805051 100644
--- a/lib/librte_security/rte_security.c
+++ b/lib/librte_security/rte_security.c
@@ -108,6 +108,18 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 					       sess, m, params);
 }
 
+void *
+rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md)
+{
+	void *userdata = NULL;
+
+	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_userdata, NULL);
+	if (instance->ops->get_userdata(instance->device, md, &userdata))
+		return NULL;
+
+	return userdata;
+}
+
 const struct rte_security_capability *
 rte_security_capabilities_get(struct rte_security_ctx *instance)
 {
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index 653929b..a34cbba 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -274,6 +274,8 @@ struct rte_security_session_conf {
 	/**< Configuration parameters for security session */
 	struct rte_crypto_sym_xform *crypto_xform;
 	/**< Security Session Crypto Transformations */
+	void *userdata;
+	/**< Application specific userdata to be saved with session */
 };
 
 struct rte_security_session {
@@ -346,6 +348,24 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 			      struct rte_mbuf *mb, void *params);
 
 /**
+ * Get userdata associated with the security session which processed the
+ * packet. This userdata would be registered while creating the session, and
+ * application can use this to identify the SA etc. Device-specific metadata
+ * in the mbuf would be used for this.
+ *
+ * This is valid only for inline processed ingress packets.
+ *
+ * @param   instance	security instance
+ * @param   md		device-specific metadata set in mbuf
+ *
+ * @return
+ *  - On success, userdata
+ *  - On failure, NULL
+ */
+void *
+rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md);
+
+/**
  * Attach a session to a symmetric crypto operation
  *
  * @param	sym_op	crypto operation
diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
index 997fbe7..4e93362 100644
--- a/lib/librte_security/rte_security_driver.h
+++ b/lib/librte_security/rte_security_driver.h
@@ -122,6 +122,22 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
 		void *params);
 
 /**
+ * Get application specific userdata associated with the security session which
+ * processed the packet. This would be retrieved using the metadata obtained
+ * from packet.
+ *
+ * @param	device		Crypto/eth device pointer
+ * @param	md		Metadata
+ * @param	userdata	Pointer to receive userdata
+ *
+ * @return
+ *  - Returns 0 if userdata is retrieved successfully.
+ *  - Returns -ve value for errors.
+ */
+typedef int (*security_get_userdata_t)(void *device,
+		uint64_t md, void **userdata);
+
+/**
  * Get security capabilities of the device.
  *
  * @param	device		crypto/eth device pointer
@@ -145,6 +161,8 @@ struct rte_security_ops {
 	/**< Clear a security sessions private data. */
 	security_set_pkt_metadata_t set_pkt_metadata;
 	/**< Update mbuf metadata. */
+	security_get_userdata_t get_userdata;
+	/**< Get userdata associated with session which processed the packet. */
 	security_capabilities_get_t capabilities_get;
 	/**< Get security capabilities. */
 };
diff --git a/lib/librte_security/rte_security_version.map b/lib/librte_security/rte_security_version.map
index e12c04b..87f35d7 100644
--- a/lib/librte_security/rte_security_version.map
+++ b/lib/librte_security/rte_security_version.map
@@ -9,6 +9,7 @@ EXPERIMENTAL {
 	rte_security_session_stats_get;
 	rte_security_session_update;
 	rte_security_set_pkt_metadata;
+	rte_security_get_userdata;
 
 	local: *;
 };
-- 
2.7.4

[dpdk-dev] [PATCH v4 2/2] examples/ipsec-secgw: add support for inline protocol

[Anoob Joseph]

Adding support for inline protocol processing

In ingress side, application will receive regular IP packets, without
any IPsec related info. Application will do a selector check (SP-SA
check) by making use of the metadata from the packet. The
device-specific metadata in mbuf would aid in determing the security
session which processed the packet.

In egress side, the plain packet would be submitted to the driver. The
packet will have optional metadata, which could be used to identify the
security session associated with the packet.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v4:
* Directly using rte_mbuf.udata64 as the metadata from the packet
* Removed usage of rte_security_get_pkt_metadata API

v3:
* Using (void *)userdata instead of 64 bit metadata in conf
* Changes parallel to the change in API

v2:
* Using get_pkt_metadata API instead of get_session & get_cookie APIs

 examples/ipsec-secgw/esp.c         |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c |  42 ++++++++++++-
 examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
 3 files changed, 147 insertions(+), 22 deletions(-)

diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index c3efe52..561f873 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
 	RTE_ASSERT(sa != NULL);
 	RTE_ASSERT(cop != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
 			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
 				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
@@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
 	RTE_ASSERT(m != NULL);
 	RTE_ASSERT(sa != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
 	} else {
 		RTE_ASSERT(cop != NULL);
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index c98454a..5400660 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
 		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
 		rte_pktmbuf_free(pkt);
 	}
+
+	/* Check if the packet has been processed inline. For inline protocol
+	 * processed packets, the metadata in the mbuf can be used to identify
+	 * the security processing done on the packet. The metadata will be
+	 * used to retrieve the application registered userdata associated
+	 * with the security session.
+	 * */
+
+	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
+		struct ipsec_sa *sa;
+		struct ipsec_mbuf_metadata *priv;
+		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
+						rte_eth_dev_get_sec_ctx(
+						pkt->port);
+
+		/* Retrieve the userdata registered. Here, the userdata
+		 * registered is the SA pointer.
+		 * */
+
+		sa = (struct ipsec_sa *)
+				rte_security_get_userdata(ctx, pkt->udata64);
+
+		if (sa == NULL) {
+			/* userdata could not be retrieved */
+			return;
+		}
+
+		/* Save SA as priv member in mbuf. This will be used in the
+		 * IPsec selector(SP-SA) check.
+		 */
+
+		priv = get_priv(pkt);
+		priv->sa = sa;
+	}
 }
 
 static inline void
@@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
 			ip->pkts[j++] = m;
 			continue;
 		}
-		if (res & DISCARD || i < lim) {
+		if (res & DISCARD) {
 			rte_pktmbuf_free(m);
 			continue;
 		}
+
 		/* Only check SPI match for processed IPSec packets */
+		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
+			rte_pktmbuf_free(m);
+			continue;
+		}
+
 		sa_idx = ip->res[i] & PROTECT_MASK;
 		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
 			rte_pktmbuf_free(m);
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 70ed227..bd68ec6 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -46,6 +46,27 @@
 #include "ipsec.h"
 #include "esp.h"
 
+static inline void
+set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
+{
+	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
+		struct rte_security_ipsec_tunnel_param *tunnel =
+				&ipsec->tunnel;
+		if (sa->flags == IP4_TUNNEL) {
+			tunnel->type =
+				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
+			tunnel->ipv4.ttl = IPDEFTTL;
+
+			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
+				(uint8_t *)&sa->src.ip.ip4, 4);
+
+			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
+				(uint8_t *)&sa->dst.ip.ip4, 4);
+		}
+		/* TODO support for Transport and IPV6 tunnel */
+	}
+}
+
 static inline int
 create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 {
@@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
 					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
 			} },
-			.crypto_xform = sa->xforms
+			.crypto_xform = sa->xforms,
+			.userdata = NULL,
 
 		};
 
@@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 							rte_cryptodev_get_sec_ctx(
 							ipsec_ctx->tbl[cdev_id_qp].id);
 
-			if (sess_conf.ipsec.mode ==
-					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
-				struct rte_security_ipsec_tunnel_param *tunnel =
-						&sess_conf.ipsec.tunnel;
-				if (sa->flags == IP4_TUNNEL) {
-					tunnel->type =
-						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
-					tunnel->ipv4.ttl = IPDEFTTL;
-
-					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
-						(uint8_t *)&sa->src.ip.ip4, 4);
-
-					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
-						(uint8_t *)&sa->dst.ip.ip4, 4);
-				}
-				/* TODO support for Transport and IPV6 tunnel */
-			}
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
 
 			sa->sec_session = rte_security_session_create(ctx,
 					&sess_conf, ipsec_ctx->session_pool);
@@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					err.message);
 				return -1;
 			}
+		} else if (sa->type ==
+				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
+			struct rte_security_ctx *ctx =
+					(struct rte_security_ctx *)
+					rte_eth_dev_get_sec_ctx(sa->portid);
+			const struct rte_security_capability *sec_cap;
+
+			if (ctx == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"Ethernet device doesn't have security features registered\n");
+				return -1;
+			}
+
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
+
+			/* Save SA as userdata for the security session. When
+			 * the packet is received, this userdata will be
+			 * retrieved using the metadata from the packet.
+			 *
+			 * This is required only for inbound SAs.
+			 */
+
+			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
+				sess_conf.userdata = (void *) sa;
+
+			sa->sec_session = rte_security_session_create(ctx,
+					&sess_conf, ipsec_ctx->session_pool);
+			if (sa->sec_session == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"SEC Session init failed: err: %d\n", ret);
+				return -1;
+			}
+
+			sec_cap = rte_security_capabilities_get(ctx);
+
+			if (sec_cap == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"No capabilities registered\n");
+				return -1;
+			}
+
+			/* iterate until ESP tunnel*/
+			while (sec_cap->action !=
+					RTE_SECURITY_ACTION_TYPE_NONE) {
+
+				if (sec_cap->action == sa->type &&
+				    sec_cap->protocol ==
+					RTE_SECURITY_PROTOCOL_IPSEC &&
+				    sec_cap->ipsec.mode ==
+					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
+				    sec_cap->ipsec.direction == sa->direction)
+					break;
+				sec_cap++;
+			}
+
+			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
+				RTE_LOG(ERR, IPSEC,
+				"No suitable security capability found\n");
+				return -1;
+			}
+
+			sa->ol_flags = sec_cap->ol_flags;
+			sa->security_ctx = ctx;
 		}
 	} else {
 		sa->crypto_session = rte_cryptodev_sym_session_create(
@@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
 			}
 			break;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-			break;
+			if ((unlikely(sa->sec_session == NULL)) &&
+					create_session(ipsec_ctx, sa)) {
+				rte_pktmbuf_free(pkts[i]);
+				continue;
+			}
+
+			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
+			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
+			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
+				rte_security_set_pkt_metadata(
+						sa->security_ctx,
+						sa->sec_session, pkts[i], NULL);
+			continue;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
 			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
 			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
-- 
2.7.4

[dpdk-dev] [PATCH v5 0/2] add inline protocol support

[Anoob Joseph]

The series adds inline protocol support in DPDK.

First patch introduces changes in lib to enable applications to save a
(void *) pointer as "userdata" in security session. For inline processed
packets, applications would use the metadata field in the mbuf
(rte_mbuf.udata64) to retrieve the userdata registered for the security
session which processed the packet. The metadata would be device
specific.

This is primarily required for inline protocol processed ingress
packets. For such packets, the packet may not have enough information to
identify the security parameters with which the packet was processed.
Application can register what it needs to identify the required
parameter. The userdata will be set while creating the security
session.

Second patch adds support for inline protocol in ipsec-secgw
application

Anoob Joseph (2):
  lib/security: add support for get metadata
  examples/ipsec-secgw: add support for inline protocol

 doc/guides/prog_guide/rte_security.rst       |  22 ++++-
 examples/ipsec-secgw/esp.c                   |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c           |  42 +++++++++-
 examples/ipsec-secgw/ipsec.c                 | 121 ++++++++++++++++++++++-----
 lib/librte_security/rte_security.c           |  12 +++
 lib/librte_security/rte_security.h           |  20 +++++
 lib/librte_security/rte_security_driver.h    |  18 ++++
 lib/librte_security/rte_security_version.map |   1 +
 8 files changed, 219 insertions(+), 23 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata

[Anoob Joseph]

In case of inline protocol processed ingress traffic, the packet may not
have enough information to determine the security parameters with which
the packet was processed. In such cases, application could get metadata
from the packet which could be used to identify the security parameters
with which the packet was processed.

Application could register "userdata" with the security session, and
this could be retrieved from the metadata of inline processed packets.
The metadata returned by "rte_security_get_pkt_metadata()" will be
device specific. Also the driver is expected to return the application
registered "userdata" as is, without any modifications.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v5:
* No change

v4:
* Documented the usage of rte_mbuf.udata64 field by security library
* Removed (rte_security_get_pkt_metadata() API as the udata64 field itself
  will have device-specific metadata, and could be directly used

v3:
* Replaced 64 bit metadata in conf with (void *)userdata
* The API(rte_security_get_pkt_metadata) would return void * instead of
  uint64_t

v2:
* Replaced get_session and get_cookie APIs with get_pkt_metadata API

 doc/guides/prog_guide/rte_security.rst       | 22 +++++++++++++++++++++-
 lib/librte_security/rte_security.c           | 12 ++++++++++++
 lib/librte_security/rte_security.h           | 20 ++++++++++++++++++++
 lib/librte_security/rte_security_driver.h    | 18 ++++++++++++++++++
 lib/librte_security/rte_security_version.map |  1 +
 5 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index 71be036..6768ebe 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -148,7 +148,9 @@ packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
 ESP/AH headers will be removed from the packet and the received packet
 will contains the decrypted packet only. The driver Rx path checks the
 descriptors and based on the crypto status sets additional flags in
-``rte_mbuf.ol_flags`` field.
+``rte_mbuf.ol_flags`` field. The driver would also set device-specific
+metadata in ``rte_mbuf.udata64`` field. This will allow the application
+to identify the security processing done on the packet.
 
 .. note::
 
@@ -421,6 +423,22 @@ For Inline Crypto and Inline protocol offload, device specific defined metadata
 updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
 ``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
 
+For inline protocol offloaded ingress traffic, the application can register a
+pointer, ``userdata`` , in the security session. When the packet is received,
+``rte_security_get_userdata()`` would return the userdata registered for the
+security session which processed the packet.
+
+.. note::
+
+    In case of inline processed packets, ``rte_mbuf.udata64`` field would be
+    used by the driver to relay information on the security processing
+    associated with the packet. In ingress, the driver would set this in Rx
+    path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
+    similar operation. The application is expected not to modify the field
+    when it has relevant info. For ingress, this device-specific 64 bit value
+    is required to derive other information (like userdata), required for
+    identifying the security processing done on the packet.
+
 Security session configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -440,6 +458,8 @@ Security Session configuration structure is defined as ``rte_security_session_co
         /**< Configuration parameters for security session */
         struct rte_crypto_sym_xform *crypto_xform;
         /**< Security Session Crypto Transformations */
+        void *userdata;
+        /**< Application specific userdata to be saved with session */
     };
 
 The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
index 1227fca..5805051 100644
--- a/lib/librte_security/rte_security.c
+++ b/lib/librte_security/rte_security.c
@@ -108,6 +108,18 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 					       sess, m, params);
 }
 
+void *
+rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md)
+{
+	void *userdata = NULL;
+
+	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_userdata, NULL);
+	if (instance->ops->get_userdata(instance->device, md, &userdata))
+		return NULL;
+
+	return userdata;
+}
+
 const struct rte_security_capability *
 rte_security_capabilities_get(struct rte_security_ctx *instance)
 {
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index 653929b..a34cbba 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -274,6 +274,8 @@ struct rte_security_session_conf {
 	/**< Configuration parameters for security session */
 	struct rte_crypto_sym_xform *crypto_xform;
 	/**< Security Session Crypto Transformations */
+	void *userdata;
+	/**< Application specific userdata to be saved with session */
 };
 
 struct rte_security_session {
@@ -346,6 +348,24 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 			      struct rte_mbuf *mb, void *params);
 
 /**
+ * Get userdata associated with the security session which processed the
+ * packet. This userdata would be registered while creating the session, and
+ * application can use this to identify the SA etc. Device-specific metadata
+ * in the mbuf would be used for this.
+ *
+ * This is valid only for inline processed ingress packets.
+ *
+ * @param   instance	security instance
+ * @param   md		device-specific metadata set in mbuf
+ *
+ * @return
+ *  - On success, userdata
+ *  - On failure, NULL
+ */
+void *
+rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md);
+
+/**
  * Attach a session to a symmetric crypto operation
  *
  * @param	sym_op	crypto operation
diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
index 997fbe7..4e93362 100644
--- a/lib/librte_security/rte_security_driver.h
+++ b/lib/librte_security/rte_security_driver.h
@@ -122,6 +122,22 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
 		void *params);
 
 /**
+ * Get application specific userdata associated with the security session which
+ * processed the packet. This would be retrieved using the metadata obtained
+ * from packet.
+ *
+ * @param	device		Crypto/eth device pointer
+ * @param	md		Metadata
+ * @param	userdata	Pointer to receive userdata
+ *
+ * @return
+ *  - Returns 0 if userdata is retrieved successfully.
+ *  - Returns -ve value for errors.
+ */
+typedef int (*security_get_userdata_t)(void *device,
+		uint64_t md, void **userdata);
+
+/**
  * Get security capabilities of the device.
  *
  * @param	device		crypto/eth device pointer
@@ -145,6 +161,8 @@ struct rte_security_ops {
 	/**< Clear a security sessions private data. */
 	security_set_pkt_metadata_t set_pkt_metadata;
 	/**< Update mbuf metadata. */
+	security_get_userdata_t get_userdata;
+	/**< Get userdata associated with session which processed the packet. */
 	security_capabilities_get_t capabilities_get;
 	/**< Get security capabilities. */
 };
diff --git a/lib/librte_security/rte_security_version.map b/lib/librte_security/rte_security_version.map
index e12c04b..87f35d7 100644
--- a/lib/librte_security/rte_security_version.map
+++ b/lib/librte_security/rte_security_version.map
@@ -9,6 +9,7 @@ EXPERIMENTAL {
 	rte_security_session_stats_get;
 	rte_security_session_update;
 	rte_security_set_pkt_metadata;
+	rte_security_get_userdata;
 
 	local: *;
 };
-- 
2.7.4

Re: [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata

[Akhil Goyal]

Hi Anoob,

On 12/15/2017 2:13 PM, Anoob Joseph wrote:

> diff --git a/lib/librte_security/rte_security_version.map b/lib/librte_security/rte_security_version.map
> index e12c04b..87f35d7 100644
> --- a/lib/librte_security/rte_security_version.map
> +++ b/lib/librte_security/rte_security_version.map
> @@ -9,6 +9,7 @@ EXPERIMENTAL {
>   	rte_security_session_stats_get;
>   	rte_security_session_update;
>   	rte_security_set_pkt_metadata;
> +	rte_security_get_userdata;
This should be in alphabetical order.
>   
>   	local: *;
>   };
> 

Re: [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata

[Anoob Joseph]

Hi Akhil,


On 12/15/2017 03:31 PM, Akhil Goyal wrote:
> Hi Anoob,
>
> On 12/15/2017 2:13 PM, Anoob Joseph wrote:
>
>> diff --git a/lib/librte_security/rte_security_version.map 
>> b/lib/librte_security/rte_security_version.map
>> index e12c04b..87f35d7 100644
>> --- a/lib/librte_security/rte_security_version.map
>> +++ b/lib/librte_security/rte_security_version.map
>> @@ -9,6 +9,7 @@ EXPERIMENTAL {
>>       rte_security_session_stats_get;
>>       rte_security_session_update;
>>       rte_security_set_pkt_metadata;
>> +    rte_security_get_userdata;
> This should be in alphabetical order.
Will update. Is there any such ordering followed in the placement of 
APIs in various .c & .h files?
>>         local: *;
>>   };
>>
>

Re: [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata

[Akhil Goyal]

Hi Anoob,

On 12/15/2017 4:23 PM, Anoob Joseph wrote:
> Hi Akhil,
> 
> 
> On 12/15/2017 03:31 PM, Akhil Goyal wrote:
>> Hi Anoob,
>>
>> On 12/15/2017 2:13 PM, Anoob Joseph wrote:
>>
>>> diff --git a/lib/librte_security/rte_security_version.map 
>>> b/lib/librte_security/rte_security_version.map
>>> index e12c04b..87f35d7 100644
>>> --- a/lib/librte_security/rte_security_version.map
>>> +++ b/lib/librte_security/rte_security_version.map
>>> @@ -9,6 +9,7 @@ EXPERIMENTAL {
>>>       rte_security_session_stats_get;
>>>       rte_security_session_update;
>>>       rte_security_set_pkt_metadata;
>>> +    rte_security_get_userdata;
>> This should be in alphabetical order.
> Will update. Is there any such ordering followed in the placement of 
> APIs in various .c & .h files?

As per my understanding, alphabetical ordering is followed in all .map 
files and doc files in DPDK. For .c and .h, there is no such ordering.
>>>         local: *;
>>>   };
>>>
>>
> 
> 

[dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol

[Anoob Joseph]

Adding support for inline protocol processing

In ingress side, application will receive regular IP packets, without
any IPsec related info. Application will do a selector check (SP-SA
check) by making use of the metadata from the packet. The
device-specific metadata in mbuf would aid in determing the security
session which processed the packet.

In egress side, the plain packet would be submitted to the driver. The
packet will have optional metadata, which could be used to identify the
security session associated with the packet.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v5:
* Fixed checkpatch reported warnings

v4:
* Directly using rte_mbuf.udata64 as the metadata from the packet
* Removed usage of rte_security_get_pkt_metadata API

v3:
* Using (void *)userdata instead of 64 bit metadata in conf
* Changes parallel to the change in API

v2:
* Using get_pkt_metadata API instead of get_session & get_cookie APIs

 examples/ipsec-secgw/esp.c         |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c |  42 ++++++++++++-
 examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
 3 files changed, 147 insertions(+), 22 deletions(-)

diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index c3efe52..561f873 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
 	RTE_ASSERT(sa != NULL);
 	RTE_ASSERT(cop != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
 			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
 				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
@@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
 	RTE_ASSERT(m != NULL);
 	RTE_ASSERT(sa != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
 	} else {
 		RTE_ASSERT(cop != NULL);
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index c98454a..8254056 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
 		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
 		rte_pktmbuf_free(pkt);
 	}
+
+	/* Check if the packet has been processed inline. For inline protocol
+	 * processed packets, the metadata in the mbuf can be used to identify
+	 * the security processing done on the packet. The metadata will be
+	 * used to retrieve the application registered userdata associated
+	 * with the security session.
+	 */
+
+	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
+		struct ipsec_sa *sa;
+		struct ipsec_mbuf_metadata *priv;
+		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
+						rte_eth_dev_get_sec_ctx(
+						pkt->port);
+
+		/* Retrieve the userdata registered. Here, the userdata
+		 * registered is the SA pointer.
+		 */
+
+		sa = (struct ipsec_sa *)
+				rte_security_get_userdata(ctx, pkt->udata64);
+
+		if (sa == NULL) {
+			/* userdata could not be retrieved */
+			return;
+		}
+
+		/* Save SA as priv member in mbuf. This will be used in the
+		 * IPsec selector(SP-SA) check.
+		 */
+
+		priv = get_priv(pkt);
+		priv->sa = sa;
+	}
 }
 
 static inline void
@@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
 			ip->pkts[j++] = m;
 			continue;
 		}
-		if (res & DISCARD || i < lim) {
+		if (res & DISCARD) {
 			rte_pktmbuf_free(m);
 			continue;
 		}
+
 		/* Only check SPI match for processed IPSec packets */
+		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
+			rte_pktmbuf_free(m);
+			continue;
+		}
+
 		sa_idx = ip->res[i] & PROTECT_MASK;
 		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
 			rte_pktmbuf_free(m);
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 70ed227..bd68ec6 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -46,6 +46,27 @@
 #include "ipsec.h"
 #include "esp.h"
 
+static inline void
+set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
+{
+	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
+		struct rte_security_ipsec_tunnel_param *tunnel =
+				&ipsec->tunnel;
+		if (sa->flags == IP4_TUNNEL) {
+			tunnel->type =
+				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
+			tunnel->ipv4.ttl = IPDEFTTL;
+
+			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
+				(uint8_t *)&sa->src.ip.ip4, 4);
+
+			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
+				(uint8_t *)&sa->dst.ip.ip4, 4);
+		}
+		/* TODO support for Transport and IPV6 tunnel */
+	}
+}
+
 static inline int
 create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 {
@@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
 					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
 			} },
-			.crypto_xform = sa->xforms
+			.crypto_xform = sa->xforms,
+			.userdata = NULL,
 
 		};
 
@@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 							rte_cryptodev_get_sec_ctx(
 							ipsec_ctx->tbl[cdev_id_qp].id);
 
-			if (sess_conf.ipsec.mode ==
-					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
-				struct rte_security_ipsec_tunnel_param *tunnel =
-						&sess_conf.ipsec.tunnel;
-				if (sa->flags == IP4_TUNNEL) {
-					tunnel->type =
-						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
-					tunnel->ipv4.ttl = IPDEFTTL;
-
-					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
-						(uint8_t *)&sa->src.ip.ip4, 4);
-
-					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
-						(uint8_t *)&sa->dst.ip.ip4, 4);
-				}
-				/* TODO support for Transport and IPV6 tunnel */
-			}
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
 
 			sa->sec_session = rte_security_session_create(ctx,
 					&sess_conf, ipsec_ctx->session_pool);
@@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					err.message);
 				return -1;
 			}
+		} else if (sa->type ==
+				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
+			struct rte_security_ctx *ctx =
+					(struct rte_security_ctx *)
+					rte_eth_dev_get_sec_ctx(sa->portid);
+			const struct rte_security_capability *sec_cap;
+
+			if (ctx == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"Ethernet device doesn't have security features registered\n");
+				return -1;
+			}
+
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
+
+			/* Save SA as userdata for the security session. When
+			 * the packet is received, this userdata will be
+			 * retrieved using the metadata from the packet.
+			 *
+			 * This is required only for inbound SAs.
+			 */
+
+			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
+				sess_conf.userdata = (void *) sa;
+
+			sa->sec_session = rte_security_session_create(ctx,
+					&sess_conf, ipsec_ctx->session_pool);
+			if (sa->sec_session == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"SEC Session init failed: err: %d\n", ret);
+				return -1;
+			}
+
+			sec_cap = rte_security_capabilities_get(ctx);
+
+			if (sec_cap == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"No capabilities registered\n");
+				return -1;
+			}
+
+			/* iterate until ESP tunnel*/
+			while (sec_cap->action !=
+					RTE_SECURITY_ACTION_TYPE_NONE) {
+
+				if (sec_cap->action == sa->type &&
+				    sec_cap->protocol ==
+					RTE_SECURITY_PROTOCOL_IPSEC &&
+				    sec_cap->ipsec.mode ==
+					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
+				    sec_cap->ipsec.direction == sa->direction)
+					break;
+				sec_cap++;
+			}
+
+			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
+				RTE_LOG(ERR, IPSEC,
+				"No suitable security capability found\n");
+				return -1;
+			}
+
+			sa->ol_flags = sec_cap->ol_flags;
+			sa->security_ctx = ctx;
 		}
 	} else {
 		sa->crypto_session = rte_cryptodev_sym_session_create(
@@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
 			}
 			break;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-			break;
+			if ((unlikely(sa->sec_session == NULL)) &&
+					create_session(ipsec_ctx, sa)) {
+				rte_pktmbuf_free(pkts[i]);
+				continue;
+			}
+
+			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
+			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
+			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
+				rte_security_set_pkt_metadata(
+						sa->security_ctx,
+						sa->sec_session, pkts[i], NULL);
+			continue;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
 			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
 			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
-- 
2.7.4

Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol

[Nelio Laranjeiro]

Hi Anoob,

On Fri, Dec 15, 2017 at 08:43:16AM +0000, Anoob Joseph wrote:
> Adding support for inline protocol processing
> 
> In ingress side, application will receive regular IP packets, without
> any IPsec related info. Application will do a selector check (SP-SA
> check) by making use of the metadata from the packet. The
> device-specific metadata in mbuf would aid in determing the security
> session which processed the packet.

This means that your devices removes the tunnel header?  What happens
for packets which could not be decrypted correctly, is also the header
removed?
Anyway this description is wrong as it is not true for all inline
devices.

In addition, in ingress, the same result can be archived by using a mark
id to identify the flow and thus its security association.

> In egress side, the plain packet would be submitted to the driver. The
> packet will have optional metadata, which could be used to identify the
> security session associated with the packet.

Not true for all inline devices, some only need the next-proto for the
ESP part.

> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
> v5:
> * Fixed checkpatch reported warnings
> 
> v4:
> * Directly using rte_mbuf.udata64 as the metadata from the packet
> * Removed usage of rte_security_get_pkt_metadata API
> 
> v3:
> * Using (void *)userdata instead of 64 bit metadata in conf
> * Changes parallel to the change in API
> 
> v2:
> * Using get_pkt_metadata API instead of get_session & get_cookie APIs
> 
>  examples/ipsec-secgw/esp.c         |   6 +-
>  examples/ipsec-secgw/ipsec-secgw.c |  42 ++++++++++++-
>  examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
>  3 files changed, 147 insertions(+), 22 deletions(-)
> 
> diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
> index c3efe52..561f873 100644
> --- a/examples/ipsec-secgw/esp.c
> +++ b/examples/ipsec-secgw/esp.c
> @@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
>  	RTE_ASSERT(sa != NULL);
>  	RTE_ASSERT(cop != NULL);
>  
> -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
> +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
> +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>  		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
>  			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
>  				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
> @@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
>  	RTE_ASSERT(m != NULL);
>  	RTE_ASSERT(sa != NULL);
>  
> -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
> +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
> +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>  		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
>  	} else {
>  		RTE_ASSERT(cop != NULL);
> diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
> index c98454a..8254056 100644
> --- a/examples/ipsec-secgw/ipsec-secgw.c
> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> @@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
>  		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
>  		rte_pktmbuf_free(pkt);
>  	}
> +
> +	/* Check if the packet has been processed inline. For inline protocol
> +	 * processed packets, the metadata in the mbuf can be used to identify
> +	 * the security processing done on the packet. The metadata will be
> +	 * used to retrieve the application registered userdata associated
> +	 * with the security session.
> +	 */
> +
> +	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
> +		struct ipsec_sa *sa;
> +		struct ipsec_mbuf_metadata *priv;
> +		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
> +						rte_eth_dev_get_sec_ctx(
> +						pkt->port);
> +
> +		/* Retrieve the userdata registered. Here, the userdata
> +		 * registered is the SA pointer.
> +		 */
> +
> +		sa = (struct ipsec_sa *)
> +				rte_security_get_userdata(ctx, pkt->udata64);
> +
> +		if (sa == NULL) {
> +			/* userdata could not be retrieved */
> +			return;
> +		}
> +
> +		/* Save SA as priv member in mbuf. This will be used in the
> +		 * IPsec selector(SP-SA) check.
> +		 */
> +
> +		priv = get_priv(pkt);
> +		priv->sa = sa;
> +	}

You must verify the function exists on all drivers, those who don't
support such userdata to be inserted won't implement it.

What happens on security session where the application don't set such
information?  How the application knows the pointer is set correctly?

>  }
>  
>  static inline void
> @@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
>  			ip->pkts[j++] = m;
>  			continue;
>  		}
> -		if (res & DISCARD || i < lim) {
> +		if (res & DISCARD) {
>  			rte_pktmbuf_free(m);
>  			continue;
>  		}
> +
>  		/* Only check SPI match for processed IPSec packets */
> +		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
> +			rte_pktmbuf_free(m);
> +			continue;
> +		}
> +
>  		sa_idx = ip->res[i] & PROTECT_MASK;
>  		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
>  			rte_pktmbuf_free(m);
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index 70ed227..bd68ec6 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -46,6 +46,27 @@
>  #include "ipsec.h"
>  #include "esp.h"
>  
> +static inline void
> +set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
> +{
> +	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
> +		struct rte_security_ipsec_tunnel_param *tunnel =
> +				&ipsec->tunnel;
> +		if (sa->flags == IP4_TUNNEL) {
> +			tunnel->type =
> +				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
> +			tunnel->ipv4.ttl = IPDEFTTL;
> +
> +			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
> +				(uint8_t *)&sa->src.ip.ip4, 4);
> +
> +			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
> +				(uint8_t *)&sa->dst.ip.ip4, 4);
> +		}
> +		/* TODO support for Transport and IPV6 tunnel */
> +	}
> +}
> +
>  static inline int
>  create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>  {
> @@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>  					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
>  					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
>  			} },
> -			.crypto_xform = sa->xforms
> +			.crypto_xform = sa->xforms,
> +			.userdata = NULL,
>  
>  		};
>  
> @@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>  							rte_cryptodev_get_sec_ctx(
>  							ipsec_ctx->tbl[cdev_id_qp].id);
>  
> -			if (sess_conf.ipsec.mode ==
> -					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
> -				struct rte_security_ipsec_tunnel_param *tunnel =
> -						&sess_conf.ipsec.tunnel;
> -				if (sa->flags == IP4_TUNNEL) {
> -					tunnel->type =
> -						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
> -					tunnel->ipv4.ttl = IPDEFTTL;
> -
> -					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
> -						(uint8_t *)&sa->src.ip.ip4, 4);
> -
> -					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
> -						(uint8_t *)&sa->dst.ip.ip4, 4);
> -				}
> -				/* TODO support for Transport and IPV6 tunnel */
> -			}
> +			/* Set IPsec parameters in conf */
> +			set_ipsec_conf(sa, &(sess_conf.ipsec));
>  
>  			sa->sec_session = rte_security_session_create(ctx,
>  					&sess_conf, ipsec_ctx->session_pool);
> @@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>  					err.message);
>  				return -1;
>  			}
> +		} else if (sa->type ==
> +				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
> +			struct rte_security_ctx *ctx =
> +					(struct rte_security_ctx *)
> +					rte_eth_dev_get_sec_ctx(sa->portid);
> +			const struct rte_security_capability *sec_cap;
> +
> +			if (ctx == NULL) {
> +				RTE_LOG(ERR, IPSEC,
> +				"Ethernet device doesn't have security features registered\n");
> +				return -1;
> +			}
> +
> +			/* Set IPsec parameters in conf */
> +			set_ipsec_conf(sa, &(sess_conf.ipsec));
> +
> +			/* Save SA as userdata for the security session. When
> +			 * the packet is received, this userdata will be
> +			 * retrieved using the metadata from the packet.
> +			 *
> +			 * This is required only for inbound SAs.
> +			 */

Again not true for all inline devices.

> +
> +			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
> +				sess_conf.userdata = (void *) sa;
> +
> +			sa->sec_session = rte_security_session_create(ctx,
> +					&sess_conf, ipsec_ctx->session_pool);
> +			if (sa->sec_session == NULL) {
> +				RTE_LOG(ERR, IPSEC,
> +				"SEC Session init failed: err: %d\n", ret);
> +				return -1;
> +			}
> +
> +			sec_cap = rte_security_capabilities_get(ctx);
> +
> +			if (sec_cap == NULL) {
> +				RTE_LOG(ERR, IPSEC,
> +				"No capabilities registered\n");
> +				return -1;
> +			}
> +
> +			/* iterate until ESP tunnel*/
> +			while (sec_cap->action !=
> +					RTE_SECURITY_ACTION_TYPE_NONE) {
> +
> +				if (sec_cap->action == sa->type &&
> +				    sec_cap->protocol ==
> +					RTE_SECURITY_PROTOCOL_IPSEC &&
> +				    sec_cap->ipsec.mode ==
> +					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
> +				    sec_cap->ipsec.direction == sa->direction)
> +					break;
> +				sec_cap++;
> +			}
> +
> +			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
> +				RTE_LOG(ERR, IPSEC,
> +				"No suitable security capability found\n");
> +				return -1;
> +			}
> +
> +			sa->ol_flags = sec_cap->ol_flags;
> +			sa->security_ctx = ctx;
>  		}
>  	} else {
>  		sa->crypto_session = rte_cryptodev_sym_session_create(
> @@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
>  			}
>  			break;
>  		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
> -			break;
> +			if ((unlikely(sa->sec_session == NULL)) &&
> +					create_session(ipsec_ctx, sa)) {
> +				rte_pktmbuf_free(pkts[i]);
> +				continue;
> +			}
> +
> +			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
> +			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
> +			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
> +				rte_security_set_pkt_metadata(
> +						sa->security_ctx,
> +						sa->sec_session, pkts[i], NULL);
> +			continue;
>  		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
>  			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
>  			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
> -- 
> 2.7.4
> 

Thanks,

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol

[Anoob Joseph]

Hi Nelio,


On 12/15/2017 03:09 PM, Nelio Laranjeiro wrote:
> Hi Anoob,
>
> On Fri, Dec 15, 2017 at 08:43:16AM +0000, Anoob Joseph wrote:
>> Adding support for inline protocol processing
>>
>> In ingress side, application will receive regular IP packets, without
>> any IPsec related info. Application will do a selector check (SP-SA
>> check) by making use of the metadata from the packet. The
>> device-specific metadata in mbuf would aid in determing the security
>> session which processed the packet.
> This means that your devices removes the tunnel header?  What happens
> for packets which could not be decrypted correctly, is also the header
> removed?
> Anyway this description is wrong as it is not true for all inline
> devices.
This is particularly for inline protocol processed packets. For inline 
crypto, tunnel headers will be present, but for inline protocol tunnel 
headers need not be present.
>
> In addition, in ingress, the same result can be archived by using a mark
> id to identify the flow and thus its security association.
>
>> In egress side, the plain packet would be submitted to the driver. The
>> packet will have optional metadata, which could be used to identify the
>> security session associated with the packet.
> Not true for all inline devices, some only need the next-proto for the
> ESP part.
This is more or less existing behavior for inline crypto. Inline 
protocol shares most of it's behavior with inline crypto.
>
>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> ---
>> v5:
>> * Fixed checkpatch reported warnings
>>
>> v4:
>> * Directly using rte_mbuf.udata64 as the metadata from the packet
>> * Removed usage of rte_security_get_pkt_metadata API
>>
>> v3:
>> * Using (void *)userdata instead of 64 bit metadata in conf
>> * Changes parallel to the change in API
>>
>> v2:
>> * Using get_pkt_metadata API instead of get_session & get_cookie APIs
>>
>>   examples/ipsec-secgw/esp.c         |   6 +-
>>   examples/ipsec-secgw/ipsec-secgw.c |  42 ++++++++++++-
>>   examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
>>   3 files changed, 147 insertions(+), 22 deletions(-)
>>
>> diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
>> index c3efe52..561f873 100644
>> --- a/examples/ipsec-secgw/esp.c
>> +++ b/examples/ipsec-secgw/esp.c
>> @@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
>>   	RTE_ASSERT(sa != NULL);
>>   	RTE_ASSERT(cop != NULL);
>>   
>> -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
>> +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
>> +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>>   		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
>>   			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
>>   				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
>> @@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
>>   	RTE_ASSERT(m != NULL);
>>   	RTE_ASSERT(sa != NULL);
>>   
>> -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
>> +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
>> +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>>   		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
>>   	} else {
>>   		RTE_ASSERT(cop != NULL);
>> diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
>> index c98454a..8254056 100644
>> --- a/examples/ipsec-secgw/ipsec-secgw.c
>> +++ b/examples/ipsec-secgw/ipsec-secgw.c
>> @@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
>>   		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
>>   		rte_pktmbuf_free(pkt);
>>   	}
>> +
>> +	/* Check if the packet has been processed inline. For inline protocol
>> +	 * processed packets, the metadata in the mbuf can be used to identify
>> +	 * the security processing done on the packet. The metadata will be
>> +	 * used to retrieve the application registered userdata associated
>> +	 * with the security session.
>> +	 */
>> +
>> +	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
>> +		struct ipsec_sa *sa;
>> +		struct ipsec_mbuf_metadata *priv;
>> +		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
>> +						rte_eth_dev_get_sec_ctx(
>> +						pkt->port);
>> +
>> +		/* Retrieve the userdata registered. Here, the userdata
>> +		 * registered is the SA pointer.
>> +		 */
>> +
>> +		sa = (struct ipsec_sa *)
>> +				rte_security_get_userdata(ctx, pkt->udata64);
>> +
>> +		if (sa == NULL) {
>> +			/* userdata could not be retrieved */
>> +			return;
>> +		}
>> +
>> +		/* Save SA as priv member in mbuf. This will be used in the
>> +		 * IPsec selector(SP-SA) check.
>> +		 */
>> +
>> +		priv = get_priv(pkt);
>> +		priv->sa = sa;
>> +	}
> You must verify the function exists on all drivers, those who don't
> support such userdata to be inserted won't implement it.
That check is there in library. It will return NULL and then the 
function would exit
>
> What happens on security session where the application don't set such
> information?  How the application knows the pointer is set correctly?
Application is the one who sets and gets the pointer. If application 
doesn't set it correctly, application will not able to use it. If 
application doesn't set this, for inline protocol, the application won't 
have any information which it can use to identify the security 
processing done.
>
>>   }
>>   
>>   static inline void
>> @@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
>>   			ip->pkts[j++] = m;
>>   			continue;
>>   		}
>> -		if (res & DISCARD || i < lim) {
>> +		if (res & DISCARD) {
>>   			rte_pktmbuf_free(m);
>>   			continue;
>>   		}
>> +
>>   		/* Only check SPI match for processed IPSec packets */
>> +		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
>> +			rte_pktmbuf_free(m);
>> +			continue;
>> +		}
>> +
>>   		sa_idx = ip->res[i] & PROTECT_MASK;
>>   		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
>>   			rte_pktmbuf_free(m);
>> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
>> index 70ed227..bd68ec6 100644
>> --- a/examples/ipsec-secgw/ipsec.c
>> +++ b/examples/ipsec-secgw/ipsec.c
>> @@ -46,6 +46,27 @@
>>   #include "ipsec.h"
>>   #include "esp.h"
>>   
>> +static inline void
>> +set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
>> +{
>> +	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
>> +		struct rte_security_ipsec_tunnel_param *tunnel =
>> +				&ipsec->tunnel;
>> +		if (sa->flags == IP4_TUNNEL) {
>> +			tunnel->type =
>> +				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
>> +			tunnel->ipv4.ttl = IPDEFTTL;
>> +
>> +			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
>> +				(uint8_t *)&sa->src.ip.ip4, 4);
>> +
>> +			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
>> +				(uint8_t *)&sa->dst.ip.ip4, 4);
>> +		}
>> +		/* TODO support for Transport and IPV6 tunnel */
>> +	}
>> +}
>> +
>>   static inline int
>>   create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>>   {
>> @@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>>   					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
>>   					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
>>   			} },
>> -			.crypto_xform = sa->xforms
>> +			.crypto_xform = sa->xforms,
>> +			.userdata = NULL,
>>   
>>   		};
>>   
>> @@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>>   							rte_cryptodev_get_sec_ctx(
>>   							ipsec_ctx->tbl[cdev_id_qp].id);
>>   
>> -			if (sess_conf.ipsec.mode ==
>> -					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
>> -				struct rte_security_ipsec_tunnel_param *tunnel =
>> -						&sess_conf.ipsec.tunnel;
>> -				if (sa->flags == IP4_TUNNEL) {
>> -					tunnel->type =
>> -						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
>> -					tunnel->ipv4.ttl = IPDEFTTL;
>> -
>> -					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
>> -						(uint8_t *)&sa->src.ip.ip4, 4);
>> -
>> -					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
>> -						(uint8_t *)&sa->dst.ip.ip4, 4);
>> -				}
>> -				/* TODO support for Transport and IPV6 tunnel */
>> -			}
>> +			/* Set IPsec parameters in conf */
>> +			set_ipsec_conf(sa, &(sess_conf.ipsec));
>>   
>>   			sa->sec_session = rte_security_session_create(ctx,
>>   					&sess_conf, ipsec_ctx->session_pool);
>> @@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>>   					err.message);
>>   				return -1;
>>   			}
>> +		} else if (sa->type ==
>> +				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
>> +			struct rte_security_ctx *ctx =
>> +					(struct rte_security_ctx *)
>> +					rte_eth_dev_get_sec_ctx(sa->portid);
>> +			const struct rte_security_capability *sec_cap;
>> +
>> +			if (ctx == NULL) {
>> +				RTE_LOG(ERR, IPSEC,
>> +				"Ethernet device doesn't have security features registered\n");
>> +				return -1;
>> +			}
>> +
>> +			/* Set IPsec parameters in conf */
>> +			set_ipsec_conf(sa, &(sess_conf.ipsec));
>> +
>> +			/* Save SA as userdata for the security session. When
>> +			 * the packet is received, this userdata will be
>> +			 * retrieved using the metadata from the packet.
>> +			 *
>> +			 * This is required only for inbound SAs.
>> +			 */
> Again not true for all inline devices.
Should be valid for all inline protocol devices. May be addition of 
capability would look better?
>
>> +
>> +			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
>> +				sess_conf.userdata = (void *) sa;
>> +
>> +			sa->sec_session = rte_security_session_create(ctx,
>> +					&sess_conf, ipsec_ctx->session_pool);
>> +			if (sa->sec_session == NULL) {
>> +				RTE_LOG(ERR, IPSEC,
>> +				"SEC Session init failed: err: %d\n", ret);
>> +				return -1;
>> +			}
>> +
>> +			sec_cap = rte_security_capabilities_get(ctx);
>> +
>> +			if (sec_cap == NULL) {
>> +				RTE_LOG(ERR, IPSEC,
>> +				"No capabilities registered\n");
>> +				return -1;
>> +			}
>> +
>> +			/* iterate until ESP tunnel*/
>> +			while (sec_cap->action !=
>> +					RTE_SECURITY_ACTION_TYPE_NONE) {
>> +
>> +				if (sec_cap->action == sa->type &&
>> +				    sec_cap->protocol ==
>> +					RTE_SECURITY_PROTOCOL_IPSEC &&
>> +				    sec_cap->ipsec.mode ==
>> +					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
>> +				    sec_cap->ipsec.direction == sa->direction)
>> +					break;
>> +				sec_cap++;
>> +			}
>> +
>> +			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
>> +				RTE_LOG(ERR, IPSEC,
>> +				"No suitable security capability found\n");
>> +				return -1;
>> +			}
>> +
>> +			sa->ol_flags = sec_cap->ol_flags;
>> +			sa->security_ctx = ctx;
>>   		}
>>   	} else {
>>   		sa->crypto_session = rte_cryptodev_sym_session_create(
>> @@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
>>   			}
>>   			break;
>>   		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
>> -			break;
>> +			if ((unlikely(sa->sec_session == NULL)) &&
>> +					create_session(ipsec_ctx, sa)) {
>> +				rte_pktmbuf_free(pkts[i]);
>> +				continue;
>> +			}
>> +
>> +			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
>> +			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
>> +			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
>> +				rte_security_set_pkt_metadata(
>> +						sa->security_ctx,
>> +						sa->sec_session, pkts[i], NULL);
>> +			continue;
>>   		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
>>   			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
>>   			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
>> -- 
>> 2.7.4
>>
> Thanks,
>
Thanks,
Anoob

Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol

[Nelio Laranjeiro]

On Fri, Dec 15, 2017 at 04:33:25PM +0530, Anoob Joseph wrote:
> Hi Nelio,
> 
> 
> On 12/15/2017 03:09 PM, Nelio Laranjeiro wrote:
> > Hi Anoob,
> > 
> > On Fri, Dec 15, 2017 at 08:43:16AM +0000, Anoob Joseph wrote:
> > > Adding support for inline protocol processing
> > > 
> > > In ingress side, application will receive regular IP packets, without
> > > any IPsec related info. Application will do a selector check (SP-SA
> > > check) by making use of the metadata from the packet. The
> > > device-specific metadata in mbuf would aid in determing the security
> > > session which processed the packet.
> > This means that your devices removes the tunnel header?  What happens
> > for packets which could not be decrypted correctly, is also the header
> > removed?
> > Anyway this description is wrong as it is not true for all inline
> > devices.
> This is particularly for inline protocol processed packets. For inline
> crypto, tunnel headers will be present, but for inline protocol tunnel
> headers need not be present.

Ok, my bad, I did not see the RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL
additional flag.

Sorry,

> > In addition, in ingress, the same result can be archived by using a mark
> > id to identify the flow and thus its security association.
> > 
> > > In egress side, the plain packet would be submitted to the driver. The
> > > packet will have optional metadata, which could be used to identify the
> > > security session associated with the packet.
> > Not true for all inline devices, some only need the next-proto for the
> > ESP part.
> This is more or less existing behavior for inline crypto. Inline protocol
> shares most of it's behavior with inline crypto.
> > 
> > > Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> > > ---
> > > v5:
> > > * Fixed checkpatch reported warnings
> > > 
> > > v4:
> > > * Directly using rte_mbuf.udata64 as the metadata from the packet
> > > * Removed usage of rte_security_get_pkt_metadata API
> > > 
> > > v3:
> > > * Using (void *)userdata instead of 64 bit metadata in conf
> > > * Changes parallel to the change in API
> > > 
> > > v2:
> > > * Using get_pkt_metadata API instead of get_session & get_cookie APIs
> > > 
> > >   examples/ipsec-secgw/esp.c         |   6 +-
> > >   examples/ipsec-secgw/ipsec-secgw.c |  42 ++++++++++++-
> > >   examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
> > >   3 files changed, 147 insertions(+), 22 deletions(-)
> > > 
> > > diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
> > > index c3efe52..561f873 100644
> > > --- a/examples/ipsec-secgw/esp.c
> > > +++ b/examples/ipsec-secgw/esp.c
> > > @@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
> > >   	RTE_ASSERT(sa != NULL);
> > >   	RTE_ASSERT(cop != NULL);
> > > -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
> > > +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
> > > +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
> > >   		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
> > >   			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
> > >   				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
> > > @@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
> > >   	RTE_ASSERT(m != NULL);
> > >   	RTE_ASSERT(sa != NULL);
> > > -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
> > > +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
> > > +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
> > >   		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
> > >   	} else {
> > >   		RTE_ASSERT(cop != NULL);
> > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
> > > index c98454a..8254056 100644
> > > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > > @@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
> > >   		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
> > >   		rte_pktmbuf_free(pkt);
> > >   	}
> > > +
> > > +	/* Check if the packet has been processed inline. For inline protocol
> > > +	 * processed packets, the metadata in the mbuf can be used to identify
> > > +	 * the security processing done on the packet. The metadata will be
> > > +	 * used to retrieve the application registered userdata associated
> > > +	 * with the security session.
> > > +	 */
> > > +
> > > +	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
> > > +		struct ipsec_sa *sa;
> > > +		struct ipsec_mbuf_metadata *priv;
> > > +		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
> > > +						rte_eth_dev_get_sec_ctx(
> > > +						pkt->port);
> > > +
> > > +		/* Retrieve the userdata registered. Here, the userdata
> > > +		 * registered is the SA pointer.
> > > +		 */
> > > +
> > > +		sa = (struct ipsec_sa *)
> > > +				rte_security_get_userdata(ctx, pkt->udata64);
> > > +
> > > +		if (sa == NULL) {
> > > +			/* userdata could not be retrieved */
> > > +			return;
> > > +		}
> > > +
> > > +		/* Save SA as priv member in mbuf. This will be used in the
> > > +		 * IPsec selector(SP-SA) check.
> > > +		 */
> > > +
> > > +		priv = get_priv(pkt);
> > > +		priv->sa = sa;
> > > +	}
> > You must verify the function exists on all drivers, those who don't
> > support such userdata to be inserted won't implement it.
> That check is there in library. It will return NULL and then the function
> would exit
> > 
> > What happens on security session where the application don't set such
> > information?  How the application knows the pointer is set correctly?
> Application is the one who sets and gets the pointer. If application doesn't
> set it correctly, application will not able to use it. If application
> doesn't set this, for inline protocol, the application won't have any
> information which it can use to identify the security processing done.
> > 
> > >   }
> > >   static inline void
> > > @@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
> > >   			ip->pkts[j++] = m;
> > >   			continue;
> > >   		}
> > > -		if (res & DISCARD || i < lim) {
> > > +		if (res & DISCARD) {
> > >   			rte_pktmbuf_free(m);
> > >   			continue;
> > >   		}
> > > +
> > >   		/* Only check SPI match for processed IPSec packets */
> > > +		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
> > > +			rte_pktmbuf_free(m);
> > > +			continue;
> > > +		}
> > > +
> > >   		sa_idx = ip->res[i] & PROTECT_MASK;
> > >   		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
> > >   			rte_pktmbuf_free(m);
> > > diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> > > index 70ed227..bd68ec6 100644
> > > --- a/examples/ipsec-secgw/ipsec.c
> > > +++ b/examples/ipsec-secgw/ipsec.c
> > > @@ -46,6 +46,27 @@
> > >   #include "ipsec.h"
> > >   #include "esp.h"
> > > +static inline void
> > > +set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
> > > +{
> > > +	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
> > > +		struct rte_security_ipsec_tunnel_param *tunnel =
> > > +				&ipsec->tunnel;
> > > +		if (sa->flags == IP4_TUNNEL) {
> > > +			tunnel->type =
> > > +				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
> > > +			tunnel->ipv4.ttl = IPDEFTTL;
> > > +
> > > +			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
> > > +				(uint8_t *)&sa->src.ip.ip4, 4);
> > > +
> > > +			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
> > > +				(uint8_t *)&sa->dst.ip.ip4, 4);
> > > +		}
> > > +		/* TODO support for Transport and IPV6 tunnel */
> > > +	}
> > > +}
> > > +
> > >   static inline int
> > >   create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
> > >   {
> > > @@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
> > >   					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
> > >   					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
> > >   			} },
> > > -			.crypto_xform = sa->xforms
> > > +			.crypto_xform = sa->xforms,
> > > +			.userdata = NULL,
> > >   		};
> > > @@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
> > >   							rte_cryptodev_get_sec_ctx(
> > >   							ipsec_ctx->tbl[cdev_id_qp].id);
> > > -			if (sess_conf.ipsec.mode ==
> > > -					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
> > > -				struct rte_security_ipsec_tunnel_param *tunnel =
> > > -						&sess_conf.ipsec.tunnel;
> > > -				if (sa->flags == IP4_TUNNEL) {
> > > -					tunnel->type =
> > > -						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
> > > -					tunnel->ipv4.ttl = IPDEFTTL;
> > > -
> > > -					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
> > > -						(uint8_t *)&sa->src.ip.ip4, 4);
> > > -
> > > -					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
> > > -						(uint8_t *)&sa->dst.ip.ip4, 4);
> > > -				}
> > > -				/* TODO support for Transport and IPV6 tunnel */
> > > -			}
> > > +			/* Set IPsec parameters in conf */
> > > +			set_ipsec_conf(sa, &(sess_conf.ipsec));
> > >   			sa->sec_session = rte_security_session_create(ctx,
> > >   					&sess_conf, ipsec_ctx->session_pool);
> > > @@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
> > >   					err.message);
> > >   				return -1;
> > >   			}
> > > +		} else if (sa->type ==
> > > +				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
> > > +			struct rte_security_ctx *ctx =
> > > +					(struct rte_security_ctx *)
> > > +					rte_eth_dev_get_sec_ctx(sa->portid);
> > > +			const struct rte_security_capability *sec_cap;
> > > +
> > > +			if (ctx == NULL) {
> > > +				RTE_LOG(ERR, IPSEC,
> > > +				"Ethernet device doesn't have security features registered\n");
> > > +				return -1;
> > > +			}
> > > +
> > > +			/* Set IPsec parameters in conf */
> > > +			set_ipsec_conf(sa, &(sess_conf.ipsec));
> > > +
> > > +			/* Save SA as userdata for the security session. When
> > > +			 * the packet is received, this userdata will be
> > > +			 * retrieved using the metadata from the packet.
> > > +			 *
> > > +			 * This is required only for inbound SAs.
> > > +			 */
> > Again not true for all inline devices.
> Should be valid for all inline protocol devices. May be addition of
> capability would look better?
> > 
> > > +
> > > +			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
> > > +				sess_conf.userdata = (void *) sa;
> > > +
> > > +			sa->sec_session = rte_security_session_create(ctx,
> > > +					&sess_conf, ipsec_ctx->session_pool);
> > > +			if (sa->sec_session == NULL) {
> > > +				RTE_LOG(ERR, IPSEC,
> > > +				"SEC Session init failed: err: %d\n", ret);
> > > +				return -1;
> > > +			}
> > > +
> > > +			sec_cap = rte_security_capabilities_get(ctx);
> > > +
> > > +			if (sec_cap == NULL) {
> > > +				RTE_LOG(ERR, IPSEC,
> > > +				"No capabilities registered\n");
> > > +				return -1;
> > > +			}
> > > +
> > > +			/* iterate until ESP tunnel*/
> > > +			while (sec_cap->action !=
> > > +					RTE_SECURITY_ACTION_TYPE_NONE) {
> > > +
> > > +				if (sec_cap->action == sa->type &&
> > > +				    sec_cap->protocol ==
> > > +					RTE_SECURITY_PROTOCOL_IPSEC &&
> > > +				    sec_cap->ipsec.mode ==
> > > +					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
> > > +				    sec_cap->ipsec.direction == sa->direction)
> > > +					break;
> > > +				sec_cap++;
> > > +			}
> > > +
> > > +			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
> > > +				RTE_LOG(ERR, IPSEC,
> > > +				"No suitable security capability found\n");
> > > +				return -1;
> > > +			}
> > > +
> > > +			sa->ol_flags = sec_cap->ol_flags;
> > > +			sa->security_ctx = ctx;
> > >   		}
> > >   	} else {
> > >   		sa->crypto_session = rte_cryptodev_sym_session_create(
> > > @@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
> > >   			}
> > >   			break;
> > >   		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
> > > -			break;
> > > +			if ((unlikely(sa->sec_session == NULL)) &&
> > > +					create_session(ipsec_ctx, sa)) {
> > > +				rte_pktmbuf_free(pkts[i]);
> > > +				continue;
> > > +			}
> > > +
> > > +			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
> > > +			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
> > > +			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
> > > +				rte_security_set_pkt_metadata(
> > > +						sa->security_ctx,
> > > +						sa->sec_session, pkts[i], NULL);
> > > +			continue;
> > >   		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
> > >   			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
> > >   			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
> > > -- 
> > > 2.7.4
> > > 
> > Thanks,
> > 
> Thanks,
> Anoob

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol

[Akhil Goyal]

On 12/15/2017 2:13 PM, Anoob Joseph wrote:
> Adding support for inline protocol processing
> 
> In ingress side, application will receive regular IP packets, without
> any IPsec related info. Application will do a selector check (SP-SA
> check) by making use of the metadata from the packet. The
> device-specific metadata in mbuf would aid in determing the security
> session which processed the packet.
> 
> In egress side, the plain packet would be submitted to the driver. The
> packet will have optional metadata, which could be used to identify the
> security session associated with the packet.
> 
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
> v5:
> * Fixed checkpatch reported warnings
> 
> v4:
> * Directly using rte_mbuf.udata64 as the metadata from the packet
> * Removed usage of rte_security_get_pkt_metadata API
> 
> v3:
> * Using (void *)userdata instead of 64 bit metadata in conf
> * Changes parallel to the change in API
> 
> v2:
> * Using get_pkt_metadata API instead of get_session & get_cookie APIs
> 
>   examples/ipsec-secgw/esp.c         |   6 +-
>   examples/ipsec-secgw/ipsec-secgw.c |  42 ++++++++++++-
>   examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
>   3 files changed, 147 insertions(+), 22 deletions(-)
> 
> diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
> index c3efe52..561f873 100644
> --- a/examples/ipsec-secgw/esp.c
> +++ b/examples/ipsec-secgw/esp.c
> @@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
>   	RTE_ASSERT(sa != NULL);
>   	RTE_ASSERT(cop != NULL);
>   
> -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
> +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
> +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>   		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
>   			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
>   				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
> @@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
>   	RTE_ASSERT(m != NULL);
>   	RTE_ASSERT(sa != NULL);
>   
> -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
> +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
> +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>   		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
>   	} else {
>   		RTE_ASSERT(cop != NULL);
> diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
> index c98454a..8254056 100644
> --- a/examples/ipsec-secgw/ipsec-secgw.c
> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> @@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
>   		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
>   		rte_pktmbuf_free(pkt);
>   	}
> +
> +	/* Check if the packet has been processed inline. For inline protocol
> +	 * processed packets, the metadata in the mbuf can be used to identify
> +	 * the security processing done on the packet. The metadata will be
> +	 * used to retrieve the application registered userdata associated
> +	 * with the security session.
> +	 */
> +
> +	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
> +		struct ipsec_sa *sa;
> +		struct ipsec_mbuf_metadata *priv;
> +		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
> +						rte_eth_dev_get_sec_ctx(
> +						pkt->port);
> +
> +		/* Retrieve the userdata registered. Here, the userdata
> +		 * registered is the SA pointer.
> +		 */
> +
> +		sa = (struct ipsec_sa *)
> +				rte_security_get_userdata(ctx, pkt->udata64);
> +
> +		if (sa == NULL) {
> +			/* userdata could not be retrieved */
Is it mandatory to get userdata for all devices which support 
PKT_RX_SEC_OFFLOAD? I believe not. So you cannot return from here if the 
device does not need userdata.

> +			return;
> +		}
> +
> +		/* Save SA as priv member in mbuf. This will be used in the
> +		 * IPsec selector(SP-SA) check.
> +		 */
> +
> +		priv = get_priv(pkt);
> +		priv->sa = sa;
> +	}
>   }
>   
>   static inline void
> @@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
>   			ip->pkts[j++] = m;
>   			continue;
>   		}
> -		if (res & DISCARD || i < lim) {
> +		if (res & DISCARD) {
>   			rte_pktmbuf_free(m);
>   			continue;
>   		}
> +
>   		/* Only check SPI match for processed IPSec packets */
> +		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
> +			rte_pktmbuf_free(m);
> +			continue;
> +		}
> +
>   		sa_idx = ip->res[i] & PROTECT_MASK;
>   		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
>   			rte_pktmbuf_free(m);
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index 70ed227..bd68ec6 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -46,6 +46,27 @@
>   #include "ipsec.h"
>   #include "esp.h"
>   
> +static inline void
> +set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
> +{
> +	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
> +		struct rte_security_ipsec_tunnel_param *tunnel =
> +				&ipsec->tunnel;
> +		if (sa->flags == IP4_TUNNEL) {
> +			tunnel->type =
> +				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
> +			tunnel->ipv4.ttl = IPDEFTTL;
> +
> +			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
> +				(uint8_t *)&sa->src.ip.ip4, 4);
> +
> +			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
> +				(uint8_t *)&sa->dst.ip.ip4, 4);
> +		}
> +		/* TODO support for Transport and IPV6 tunnel */
> +	}
> +}
> +
>   static inline int
>   create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   {
> @@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
>   					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
>   			} },
> -			.crypto_xform = sa->xforms
> +			.crypto_xform = sa->xforms,
> +			.userdata = NULL,
>   
>   		};
>   
> @@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   							rte_cryptodev_get_sec_ctx(
>   							ipsec_ctx->tbl[cdev_id_qp].id);
>   
> -			if (sess_conf.ipsec.mode ==
> -					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
> -				struct rte_security_ipsec_tunnel_param *tunnel =
> -						&sess_conf.ipsec.tunnel;
> -				if (sa->flags == IP4_TUNNEL) {
> -					tunnel->type =
> -						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
> -					tunnel->ipv4.ttl = IPDEFTTL;
> -
> -					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
> -						(uint8_t *)&sa->src.ip.ip4, 4);
> -
> -					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
> -						(uint8_t *)&sa->dst.ip.ip4, 4);
> -				}
> -				/* TODO support for Transport and IPV6 tunnel */
> -			}
> +			/* Set IPsec parameters in conf */
> +			set_ipsec_conf(sa, &(sess_conf.ipsec));
>   
>   			sa->sec_session = rte_security_session_create(ctx,
>   					&sess_conf, ipsec_ctx->session_pool);
> @@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   					err.message);
>   				return -1;
>   			}
> +		} else if (sa->type ==
> +				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
> +			struct rte_security_ctx *ctx =
> +					(struct rte_security_ctx *)
> +					rte_eth_dev_get_sec_ctx(sa->portid);
> +			const struct rte_security_capability *sec_cap;
> +
> +			if (ctx == NULL) {
> +				RTE_LOG(ERR, IPSEC,
> +				"Ethernet device doesn't have security features registered\n");
> +				return -1;
> +			}
> +
> +			/* Set IPsec parameters in conf */
> +			set_ipsec_conf(sa, &(sess_conf.ipsec));
> +
> +			/* Save SA as userdata for the security session. When
> +			 * the packet is received, this userdata will be
> +			 * retrieved using the metadata from the packet.
> +			 *
> +			 * This is required only for inbound SAs.
> +			 */
> +
> +			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
> +				sess_conf.userdata = (void *) sa;
> +
> +			sa->sec_session = rte_security_session_create(ctx,
> +					&sess_conf, ipsec_ctx->session_pool);
> +			if (sa->sec_session == NULL) {
> +				RTE_LOG(ERR, IPSEC,
> +				"SEC Session init failed: err: %d\n", ret);
> +				return -1;
> +			}
> +
> +			sec_cap = rte_security_capabilities_get(ctx);
> +
> +			if (sec_cap == NULL) {
> +				RTE_LOG(ERR, IPSEC,
> +				"No capabilities registered\n");
> +				return -1;
> +			}
> +
> +			/* iterate until ESP tunnel*/
> +			while (sec_cap->action !=
> +					RTE_SECURITY_ACTION_TYPE_NONE) {
> +
> +				if (sec_cap->action == sa->type &&
> +				    sec_cap->protocol ==
> +					RTE_SECURITY_PROTOCOL_IPSEC &&
> +				    sec_cap->ipsec.mode ==
> +					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
> +				    sec_cap->ipsec.direction == sa->direction)
> +					break;
> +				sec_cap++;
> +			}
> +
> +			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
> +				RTE_LOG(ERR, IPSEC,
> +				"No suitable security capability found\n");
> +				return -1;
> +			}
> +
> +			sa->ol_flags = sec_cap->ol_flags;
> +			sa->security_ctx = ctx;
>   		}
>   	} else {
>   		sa->crypto_session = rte_cryptodev_sym_session_create(
> @@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
>   			}
>   			break;
>   		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
> -			break;
> +			if ((unlikely(sa->sec_session == NULL)) &&
> +					create_session(ipsec_ctx, sa)) {
> +				rte_pktmbuf_free(pkts[i]);
> +				continue;
> +			}
> +
> +			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
> +			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
> +			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
> +				rte_security_set_pkt_metadata(
> +						sa->security_ctx,
> +						sa->sec_session, pkts[i], NULL);
> +			continue;
>   		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
>   			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
>   			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
> 

Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol

[Anoob Joseph]

Hi Akhil,


On 12/15/2017 03:34 PM, Akhil Goyal wrote:
> On 12/15/2017 2:13 PM, Anoob Joseph wrote:
>> Adding support for inline protocol processing
>>
>> In ingress side, application will receive regular IP packets, without
>> any IPsec related info. Application will do a selector check (SP-SA
>> check) by making use of the metadata from the packet. The
>> device-specific metadata in mbuf would aid in determing the security
>> session which processed the packet.
>>
>> In egress side, the plain packet would be submitted to the driver. The
>> packet will have optional metadata, which could be used to identify the
>> security session associated with the packet.
>>
>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> ---
>> v5:
>> * Fixed checkpatch reported warnings
>>
>> v4:
>> * Directly using rte_mbuf.udata64 as the metadata from the packet
>> * Removed usage of rte_security_get_pkt_metadata API
>>
>> v3:
>> * Using (void *)userdata instead of 64 bit metadata in conf
>> * Changes parallel to the change in API
>>
>> v2:
>> * Using get_pkt_metadata API instead of get_session & get_cookie APIs
>>
>>   examples/ipsec-secgw/esp.c         |   6 +-
>>   examples/ipsec-secgw/ipsec-secgw.c |  42 ++++++++++++-
>>   examples/ipsec-secgw/ipsec.c       | 121 
>> +++++++++++++++++++++++++++++++------
>>   3 files changed, 147 insertions(+), 22 deletions(-)
>>
>> diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
>> index c3efe52..561f873 100644
>> --- a/examples/ipsec-secgw/esp.c
>> +++ b/examples/ipsec-secgw/esp.c
>> @@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct 
>> ipsec_sa *sa,
>>       RTE_ASSERT(sa != NULL);
>>       RTE_ASSERT(cop != NULL);
>>   -    if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
>> +    if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
>> +            (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>>           if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
>>               if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
>>                   cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
>> @@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
>>       RTE_ASSERT(m != NULL);
>>       RTE_ASSERT(sa != NULL);
>>   -    if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
>> +    if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
>> +            (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>>           m->ol_flags |= PKT_TX_SEC_OFFLOAD;
>>       } else {
>>           RTE_ASSERT(cop != NULL);
>> diff --git a/examples/ipsec-secgw/ipsec-secgw.c 
>> b/examples/ipsec-secgw/ipsec-secgw.c
>> index c98454a..8254056 100644
>> --- a/examples/ipsec-secgw/ipsec-secgw.c
>> +++ b/examples/ipsec-secgw/ipsec-secgw.c
>> @@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct 
>> ipsec_traffic *t)
>>           RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
>>           rte_pktmbuf_free(pkt);
>>       }
>> +
>> +    /* Check if the packet has been processed inline. For inline 
>> protocol
>> +     * processed packets, the metadata in the mbuf can be used to 
>> identify
>> +     * the security processing done on the packet. The metadata will be
>> +     * used to retrieve the application registered userdata associated
>> +     * with the security session.
>> +     */
>> +
>> +    if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
>> +        struct ipsec_sa *sa;
>> +        struct ipsec_mbuf_metadata *priv;
>> +        struct rte_security_ctx *ctx = (struct rte_security_ctx *)
>> +                        rte_eth_dev_get_sec_ctx(
>> +                        pkt->port);
>> +
>> +        /* Retrieve the userdata registered. Here, the userdata
>> +         * registered is the SA pointer.
>> +         */
>> +
>> +        sa = (struct ipsec_sa *)
>> +                rte_security_get_userdata(ctx, pkt->udata64);
>> +
>> +        if (sa == NULL) {
>> +            /* userdata could not be retrieved */
> Is it mandatory to get userdata for all devices which support 
> PKT_RX_SEC_OFFLOAD? I believe not. So you cannot return from here if 
> the device does not need userdata.
This code was added in the end. "return" was added because nothing else 
had to be done following this. May be I can make this code block a 
static inline function. Then it won't be misleading.

There is no flag in mbuf to differentiate between inline protocol & 
inline crypto. PKT_RX_SEC_OFFLOAD will denote that inline processing has 
been done, but not which. For inline-crypto, the "priv->sa" field will 
get (over) written, as the SA is identified. Whether inline-crypto would 
need "userdata" is open for discussions. This userdata will be valid 
only if it is set while the security session is created. Right now, we 
set it only for inline-protocol processed ones.
>
>> +            return;
>> +        }
>> +
>> +        /* Save SA as priv member in mbuf. This will be used in the
>> +         * IPsec selector(SP-SA) check.
>> +         */
>> +
>> +        priv = get_priv(pkt);
>> +        priv->sa = sa;
>> +    }
>>   }
>>     static inline void
>> @@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx 
>> *sa, struct traffic_type *ip,
>>               ip->pkts[j++] = m;
>>               continue;
>>           }
>> -        if (res & DISCARD || i < lim) {
>> +        if (res & DISCARD) {
>>               rte_pktmbuf_free(m);
>>               continue;
>>           }
>> +
>>           /* Only check SPI match for processed IPSec packets */
>> +        if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
>> +            rte_pktmbuf_free(m);
>> +            continue;
>> +        }
>> +
>>           sa_idx = ip->res[i] & PROTECT_MASK;
>>           if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
>>               rte_pktmbuf_free(m);
>> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
>> index 70ed227..bd68ec6 100644
>> --- a/examples/ipsec-secgw/ipsec.c
>> +++ b/examples/ipsec-secgw/ipsec.c
>> @@ -46,6 +46,27 @@
>>   #include "ipsec.h"
>>   #include "esp.h"
>>   +static inline void
>> +set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform 
>> *ipsec)
>> +{
>> +    if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
>> +        struct rte_security_ipsec_tunnel_param *tunnel =
>> +                &ipsec->tunnel;
>> +        if (sa->flags == IP4_TUNNEL) {
>> +            tunnel->type =
>> +                RTE_SECURITY_IPSEC_TUNNEL_IPV4;
>> +            tunnel->ipv4.ttl = IPDEFTTL;
>> +
>> +            memcpy((uint8_t *)&tunnel->ipv4.src_ip,
>> +                (uint8_t *)&sa->src.ip.ip4, 4);
>> +
>> +            memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
>> +                (uint8_t *)&sa->dst.ip.ip4, 4);
>> +        }
>> +        /* TODO support for Transport and IPV6 tunnel */
>> +    }
>> +}
>> +
>>   static inline int
>>   create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>>   {
>> @@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct 
>> ipsec_sa *sa)
>>                       RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
>>                       RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
>>               } },
>> -            .crypto_xform = sa->xforms
>> +            .crypto_xform = sa->xforms,
>> +            .userdata = NULL,
>>             };
>>   @@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, 
>> struct ipsec_sa *sa)
>>                               rte_cryptodev_get_sec_ctx(
>>                               ipsec_ctx->tbl[cdev_id_qp].id);
>>   -            if (sess_conf.ipsec.mode ==
>> -                    RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
>> -                struct rte_security_ipsec_tunnel_param *tunnel =
>> -                        &sess_conf.ipsec.tunnel;
>> -                if (sa->flags == IP4_TUNNEL) {
>> -                    tunnel->type =
>> -                        RTE_SECURITY_IPSEC_TUNNEL_IPV4;
>> -                    tunnel->ipv4.ttl = IPDEFTTL;
>> -
>> -                    memcpy((uint8_t *)&tunnel->ipv4.src_ip,
>> -                        (uint8_t *)&sa->src.ip.ip4, 4);
>> -
>> -                    memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
>> -                        (uint8_t *)&sa->dst.ip.ip4, 4);
>> -                }
>> -                /* TODO support for Transport and IPV6 tunnel */
>> -            }
>> +            /* Set IPsec parameters in conf */
>> +            set_ipsec_conf(sa, &(sess_conf.ipsec));
>>                 sa->sec_session = rte_security_session_create(ctx,
>>                       &sess_conf, ipsec_ctx->session_pool);
>> @@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, 
>> struct ipsec_sa *sa)
>>                       err.message);
>>                   return -1;
>>               }
>> +        } else if (sa->type ==
>> +                RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
>> +            struct rte_security_ctx *ctx =
>> +                    (struct rte_security_ctx *)
>> +                    rte_eth_dev_get_sec_ctx(sa->portid);
>> +            const struct rte_security_capability *sec_cap;
>> +
>> +            if (ctx == NULL) {
>> +                RTE_LOG(ERR, IPSEC,
>> +                "Ethernet device doesn't have security features 
>> registered\n");
>> +                return -1;
>> +            }
>> +
>> +            /* Set IPsec parameters in conf */
>> +            set_ipsec_conf(sa, &(sess_conf.ipsec));
>> +
>> +            /* Save SA as userdata for the security session. When
>> +             * the packet is received, this userdata will be
>> +             * retrieved using the metadata from the packet.
>> +             *
>> +             * This is required only for inbound SAs.
>> +             */
>> +
>> +            if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
>> +                sess_conf.userdata = (void *) sa;
>> +
>> +            sa->sec_session = rte_security_session_create(ctx,
>> +                    &sess_conf, ipsec_ctx->session_pool);
>> +            if (sa->sec_session == NULL) {
>> +                RTE_LOG(ERR, IPSEC,
>> +                "SEC Session init failed: err: %d\n", ret);
>> +                return -1;
>> +            }
>> +
>> +            sec_cap = rte_security_capabilities_get(ctx);
>> +
>> +            if (sec_cap == NULL) {
>> +                RTE_LOG(ERR, IPSEC,
>> +                "No capabilities registered\n");
>> +                return -1;
>> +            }
>> +
>> +            /* iterate until ESP tunnel*/
>> +            while (sec_cap->action !=
>> +                    RTE_SECURITY_ACTION_TYPE_NONE) {
>> +
>> +                if (sec_cap->action == sa->type &&
>> +                    sec_cap->protocol ==
>> +                    RTE_SECURITY_PROTOCOL_IPSEC &&
>> +                    sec_cap->ipsec.mode ==
>> +                    RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
>> +                    sec_cap->ipsec.direction == sa->direction)
>> +                    break;
>> +                sec_cap++;
>> +            }
>> +
>> +            if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
>> +                RTE_LOG(ERR, IPSEC,
>> +                "No suitable security capability found\n");
>> +                return -1;
>> +            }
>> +
>> +            sa->ol_flags = sec_cap->ol_flags;
>> +            sa->security_ctx = ctx;
>>           }
>>       } else {
>>           sa->crypto_session = rte_cryptodev_sym_session_create(
>> @@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct 
>> ipsec_ctx *ipsec_ctx,
>>               }
>>               break;
>>           case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
>> -            break;
>> +            if ((unlikely(sa->sec_session == NULL)) &&
>> +                    create_session(ipsec_ctx, sa)) {
>> +                rte_pktmbuf_free(pkts[i]);
>> +                continue;
>> +            }
>> +
>> +            cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
>> +            cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
>> +            if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
>> +                rte_security_set_pkt_metadata(
>> +                        sa->security_ctx,
>> +                        sa->sec_session, pkts[i], NULL);
>> +            continue;
>>           case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
>>               priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
>>               priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
>>
>

[dpdk-dev] [PATCH v6 0/2] add inline protocol support

[Anoob Joseph]

The series adds inline protocol support in DPDK.

First patch introduces changes in lib to enable applications to save a
(void *) pointer as "userdata" in security session. For inline processed
packets, applications would use the metadata field in the mbuf
(rte_mbuf.udata64) to retrieve the userdata registered for the security
session which processed the packet. The metadata would be device
specific.

This is primarily required for inline protocol processed ingress
packets. For such packets, the packet may not have enough information to
identify the security parameters with which the packet was processed.
Application can register what it needs to identify the required
parameter. The userdata will be set while creating the security
session.

Second patch adds support for inline protocol in ipsec-secgw
application

Anoob Joseph (2):
  lib/security: add support for get userdata
  examples/ipsec-secgw: add support for inline protocol

 doc/guides/prog_guide/rte_security.rst       |  22 ++++-
 examples/ipsec-secgw/esp.c                   |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c           |  42 +++++++++-
 examples/ipsec-secgw/ipsec.c                 | 121 ++++++++++++++++++++++-----
 lib/librte_security/rte_security.c           |  12 +++
 lib/librte_security/rte_security.h           |  20 +++++
 lib/librte_security/rte_security_driver.h    |  18 ++++
 lib/librte_security/rte_security_version.map |   1 +
 8 files changed, 219 insertions(+), 23 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata

[Anoob Joseph]

In case of inline protocol processed ingress traffic, the packet may not
have enough information to determine the security parameters with which
the packet was processed. In such cases, application could get metadata
from the packet which could be used to identify the security parameters
with which the packet was processed.

Application could register "userdata" with the security session, and
this could be retrieved from the metadata of inline processed packets.
The metadata returned by "rte_security_get_pkt_metadata()" will be
device specific. Also the driver is expected to return the application
registered "userdata" as is, without any modifications.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v6:
* The file *_version.map needs APIs to be in alphabetical order. Fixed this
  for the new API added.

v5:
* No change

v4:
* Documented the usage of rte_mbuf.udata64 field by security library
* Removed (rte_security_get_pkt_metadata() API as the udata64 field itself
  will have device-specific metadata, and could be directly used

v3:
* Replaced 64 bit metadata in conf with (void *)userdata
* The API(rte_security_get_pkt_metadata) would return void * instead of
  uint64_t

v2:
* Replaced get_session and get_cookie APIs with get_pkt_metadata API

 doc/guides/prog_guide/rte_security.rst       | 22 +++++++++++++++++++++-
 lib/librte_security/rte_security.c           | 12 ++++++++++++
 lib/librte_security/rte_security.h           | 20 ++++++++++++++++++++
 lib/librte_security/rte_security_driver.h    | 18 ++++++++++++++++++
 lib/librte_security/rte_security_version.map |  1 +
 5 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index 71be036..6768ebe 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -148,7 +148,9 @@ packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
 ESP/AH headers will be removed from the packet and the received packet
 will contains the decrypted packet only. The driver Rx path checks the
 descriptors and based on the crypto status sets additional flags in
-``rte_mbuf.ol_flags`` field.
+``rte_mbuf.ol_flags`` field. The driver would also set device-specific
+metadata in ``rte_mbuf.udata64`` field. This will allow the application
+to identify the security processing done on the packet.
 
 .. note::
 
@@ -421,6 +423,22 @@ For Inline Crypto and Inline protocol offload, device specific defined metadata
 updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
 ``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
 
+For inline protocol offloaded ingress traffic, the application can register a
+pointer, ``userdata`` , in the security session. When the packet is received,
+``rte_security_get_userdata()`` would return the userdata registered for the
+security session which processed the packet.
+
+.. note::
+
+    In case of inline processed packets, ``rte_mbuf.udata64`` field would be
+    used by the driver to relay information on the security processing
+    associated with the packet. In ingress, the driver would set this in Rx
+    path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
+    similar operation. The application is expected not to modify the field
+    when it has relevant info. For ingress, this device-specific 64 bit value
+    is required to derive other information (like userdata), required for
+    identifying the security processing done on the packet.
+
 Security session configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -440,6 +458,8 @@ Security Session configuration structure is defined as ``rte_security_session_co
         /**< Configuration parameters for security session */
         struct rte_crypto_sym_xform *crypto_xform;
         /**< Security Session Crypto Transformations */
+        void *userdata;
+        /**< Application specific userdata to be saved with session */
     };
 
 The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
index 1227fca..5805051 100644
--- a/lib/librte_security/rte_security.c
+++ b/lib/librte_security/rte_security.c
@@ -108,6 +108,18 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 					       sess, m, params);
 }
 
+void *
+rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md)
+{
+	void *userdata = NULL;
+
+	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_userdata, NULL);
+	if (instance->ops->get_userdata(instance->device, md, &userdata))
+		return NULL;
+
+	return userdata;
+}
+
 const struct rte_security_capability *
 rte_security_capabilities_get(struct rte_security_ctx *instance)
 {
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index 653929b..a34cbba 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -274,6 +274,8 @@ struct rte_security_session_conf {
 	/**< Configuration parameters for security session */
 	struct rte_crypto_sym_xform *crypto_xform;
 	/**< Security Session Crypto Transformations */
+	void *userdata;
+	/**< Application specific userdata to be saved with session */
 };
 
 struct rte_security_session {
@@ -346,6 +348,24 @@ rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
 			      struct rte_mbuf *mb, void *params);
 
 /**
+ * Get userdata associated with the security session which processed the
+ * packet. This userdata would be registered while creating the session, and
+ * application can use this to identify the SA etc. Device-specific metadata
+ * in the mbuf would be used for this.
+ *
+ * This is valid only for inline processed ingress packets.
+ *
+ * @param   instance	security instance
+ * @param   md		device-specific metadata set in mbuf
+ *
+ * @return
+ *  - On success, userdata
+ *  - On failure, NULL
+ */
+void *
+rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md);
+
+/**
  * Attach a session to a symmetric crypto operation
  *
  * @param	sym_op	crypto operation
diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
index 997fbe7..bf0170e 100644
--- a/lib/librte_security/rte_security_driver.h
+++ b/lib/librte_security/rte_security_driver.h
@@ -122,6 +122,22 @@ typedef int (*security_set_pkt_metadata_t)(void *device,
 		void *params);
 
 /**
+ * Get application specific userdata associated with the security session which
+ * processed the packet. This would be retrieved using the metadata obtained
+ * from packet.
+ *
+ * @param	device		Crypto/eth device pointer
+ * @param	md		Metadata
+ * @param	userdata	Pointer to receive userdata
+ *
+ * @return
+ *  - Returns 0 if userdata is retrieved successfully.
+ *  - Returns -ve value for errors.
+ */
+typedef int (*security_get_userdata_t)(void *device,
+		uint64_t md, void **userdata);
+
+/**
  * Get security capabilities of the device.
  *
  * @param	device		crypto/eth device pointer
@@ -145,6 +161,8 @@ struct rte_security_ops {
 	/**< Clear a security sessions private data. */
 	security_set_pkt_metadata_t set_pkt_metadata;
 	/**< Update mbuf metadata. */
+	security_get_userdata_t get_userdata;
+	/**< Get userdata associated with session which processed the packet. */
 	security_capabilities_get_t capabilities_get;
 	/**< Get security capabilities. */
 };
diff --git a/lib/librte_security/rte_security_version.map b/lib/librte_security/rte_security_version.map
index e12c04b..bff5039 100644
--- a/lib/librte_security/rte_security_version.map
+++ b/lib/librte_security/rte_security_version.map
@@ -4,6 +4,7 @@ EXPERIMENTAL {
 	rte_security_attach_session;
 	rte_security_capabilities_get;
 	rte_security_capability_get;
+	rte_security_get_userdata;
 	rte_security_session_create;
 	rte_security_session_destroy;
 	rte_security_session_stats_get;
-- 
2.7.4

Re: [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata

[Akhil Goyal]

On 12/18/2017 12:45 PM, Anoob Joseph wrote:
> In case of inline protocol processed ingress traffic, the packet may not
> have enough information to determine the security parameters with which
> the packet was processed. In such cases, application could get metadata
> from the packet which could be used to identify the security parameters
> with which the packet was processed.
> 
> Application could register "userdata" with the security session, and
> this could be retrieved from the metadata of inline processed packets.
> The metadata returned by "rte_security_get_pkt_metadata()" will be
> device specific. Also the driver is expected to return the application
> registered "userdata" as is, without any modifications.
> 
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
> v6:
> * The file *_version.map needs APIs to be in alphabetical order. Fixed this
>    for the new API added.
> 
> v5:
> * No change
> 
> v4:
> * Documented the usage of rte_mbuf.udata64 field by security library
> * Removed (rte_security_get_pkt_metadata() API as the udata64 field itself
>    will have device-specific metadata, and could be directly used
> 
> v3:
> * Replaced 64 bit metadata in conf with (void *)userdata
> * The API(rte_security_get_pkt_metadata) would return void * instead of
>    uint64_t
> 
> v2:
> * Replaced get_session and get_cookie APIs with get_pkt_metadata API
> 
>   doc/guides/prog_guide/rte_security.rst       | 22 +++++++++++++++++++++-
>   lib/librte_security/rte_security.c           | 12 ++++++++++++
>   lib/librte_security/rte_security.h           | 20 ++++++++++++++++++++
>   lib/librte_security/rte_security_driver.h    | 18 ++++++++++++++++++
>   lib/librte_security/rte_security_version.map |  1 +
>   5 files changed, 72 insertions(+), 1 deletion(-)
> 
library Patch
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>

[dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol

[Anoob Joseph]

Adding support for inline protocol processing

In ingress side, application will receive regular IP packets, without
any IPsec related info. Application will do a selector check (SP-SA
check) by making use of the metadata from the packet. The
device-specific metadata in mbuf would aid in determing the security
session which processed the packet.

In egress side, the plain packet would be submitted to the driver. The
packet will have optional metadata, which could be used to identify the
security session associated with the packet.

Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
v6:
* No change

v5:
* Fixed checkpatch reported warnings

v4:
* Directly using rte_mbuf.udata64 as the metadata from the packet
* Removed usage of rte_security_get_pkt_metadata API

v3:
* Using (void *)userdata instead of 64 bit metadata in conf
* Changes parallel to the change in API

v2:
* Using get_pkt_metadata API instead of get_session & get_cookie APIs

 examples/ipsec-secgw/esp.c         |   6 +-
 examples/ipsec-secgw/ipsec-secgw.c |  42 ++++++++++++-
 examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
 3 files changed, 147 insertions(+), 22 deletions(-)

diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index c3efe52..561f873 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
 	RTE_ASSERT(sa != NULL);
 	RTE_ASSERT(cop != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
 			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
 				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
@@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
 	RTE_ASSERT(m != NULL);
 	RTE_ASSERT(sa != NULL);
 
-	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
+	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
+			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
 		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
 	} else {
 		RTE_ASSERT(cop != NULL);
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index c98454a..8254056 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
 		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
 		rte_pktmbuf_free(pkt);
 	}
+
+	/* Check if the packet has been processed inline. For inline protocol
+	 * processed packets, the metadata in the mbuf can be used to identify
+	 * the security processing done on the packet. The metadata will be
+	 * used to retrieve the application registered userdata associated
+	 * with the security session.
+	 */
+
+	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
+		struct ipsec_sa *sa;
+		struct ipsec_mbuf_metadata *priv;
+		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
+						rte_eth_dev_get_sec_ctx(
+						pkt->port);
+
+		/* Retrieve the userdata registered. Here, the userdata
+		 * registered is the SA pointer.
+		 */
+
+		sa = (struct ipsec_sa *)
+				rte_security_get_userdata(ctx, pkt->udata64);
+
+		if (sa == NULL) {
+			/* userdata could not be retrieved */
+			return;
+		}
+
+		/* Save SA as priv member in mbuf. This will be used in the
+		 * IPsec selector(SP-SA) check.
+		 */
+
+		priv = get_priv(pkt);
+		priv->sa = sa;
+	}
 }
 
 static inline void
@@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
 			ip->pkts[j++] = m;
 			continue;
 		}
-		if (res & DISCARD || i < lim) {
+		if (res & DISCARD) {
 			rte_pktmbuf_free(m);
 			continue;
 		}
+
 		/* Only check SPI match for processed IPSec packets */
+		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
+			rte_pktmbuf_free(m);
+			continue;
+		}
+
 		sa_idx = ip->res[i] & PROTECT_MASK;
 		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
 			rte_pktmbuf_free(m);
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 70ed227..bd68ec6 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -46,6 +46,27 @@
 #include "ipsec.h"
 #include "esp.h"
 
+static inline void
+set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
+{
+	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
+		struct rte_security_ipsec_tunnel_param *tunnel =
+				&ipsec->tunnel;
+		if (sa->flags == IP4_TUNNEL) {
+			tunnel->type =
+				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
+			tunnel->ipv4.ttl = IPDEFTTL;
+
+			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
+				(uint8_t *)&sa->src.ip.ip4, 4);
+
+			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
+				(uint8_t *)&sa->dst.ip.ip4, 4);
+		}
+		/* TODO support for Transport and IPV6 tunnel */
+	}
+}
+
 static inline int
 create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 {
@@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
 					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
 			} },
-			.crypto_xform = sa->xforms
+			.crypto_xform = sa->xforms,
+			.userdata = NULL,
 
 		};
 
@@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 							rte_cryptodev_get_sec_ctx(
 							ipsec_ctx->tbl[cdev_id_qp].id);
 
-			if (sess_conf.ipsec.mode ==
-					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
-				struct rte_security_ipsec_tunnel_param *tunnel =
-						&sess_conf.ipsec.tunnel;
-				if (sa->flags == IP4_TUNNEL) {
-					tunnel->type =
-						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
-					tunnel->ipv4.ttl = IPDEFTTL;
-
-					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
-						(uint8_t *)&sa->src.ip.ip4, 4);
-
-					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
-						(uint8_t *)&sa->dst.ip.ip4, 4);
-				}
-				/* TODO support for Transport and IPV6 tunnel */
-			}
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
 
 			sa->sec_session = rte_security_session_create(ctx,
 					&sess_conf, ipsec_ctx->session_pool);
@@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
 					err.message);
 				return -1;
 			}
+		} else if (sa->type ==
+				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
+			struct rte_security_ctx *ctx =
+					(struct rte_security_ctx *)
+					rte_eth_dev_get_sec_ctx(sa->portid);
+			const struct rte_security_capability *sec_cap;
+
+			if (ctx == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"Ethernet device doesn't have security features registered\n");
+				return -1;
+			}
+
+			/* Set IPsec parameters in conf */
+			set_ipsec_conf(sa, &(sess_conf.ipsec));
+
+			/* Save SA as userdata for the security session. When
+			 * the packet is received, this userdata will be
+			 * retrieved using the metadata from the packet.
+			 *
+			 * This is required only for inbound SAs.
+			 */
+
+			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
+				sess_conf.userdata = (void *) sa;
+
+			sa->sec_session = rte_security_session_create(ctx,
+					&sess_conf, ipsec_ctx->session_pool);
+			if (sa->sec_session == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"SEC Session init failed: err: %d\n", ret);
+				return -1;
+			}
+
+			sec_cap = rte_security_capabilities_get(ctx);
+
+			if (sec_cap == NULL) {
+				RTE_LOG(ERR, IPSEC,
+				"No capabilities registered\n");
+				return -1;
+			}
+
+			/* iterate until ESP tunnel*/
+			while (sec_cap->action !=
+					RTE_SECURITY_ACTION_TYPE_NONE) {
+
+				if (sec_cap->action == sa->type &&
+				    sec_cap->protocol ==
+					RTE_SECURITY_PROTOCOL_IPSEC &&
+				    sec_cap->ipsec.mode ==
+					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
+				    sec_cap->ipsec.direction == sa->direction)
+					break;
+				sec_cap++;
+			}
+
+			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
+				RTE_LOG(ERR, IPSEC,
+				"No suitable security capability found\n");
+				return -1;
+			}
+
+			sa->ol_flags = sec_cap->ol_flags;
+			sa->security_ctx = ctx;
 		}
 	} else {
 		sa->crypto_session = rte_cryptodev_sym_session_create(
@@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
 			}
 			break;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-			break;
+			if ((unlikely(sa->sec_session == NULL)) &&
+					create_session(ipsec_ctx, sa)) {
+				rte_pktmbuf_free(pkts[i]);
+				continue;
+			}
+
+			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
+			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
+			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
+				rte_security_set_pkt_metadata(
+						sa->security_ctx,
+						sa->sec_session, pkts[i], NULL);
+			continue;
 		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
 			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
 			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
-- 
2.7.4

Re: [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol

[De Lara Guarch, Pablo]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Anoob Joseph
> Sent: Monday, December 18, 2017 7:15 AM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Doherty, Declan
> <declan.doherty@intel.com>; Nicolau, Radu <radu.nicolau@intel.com>;
> Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>
> Cc: Anoob Joseph <anoob.joseph@caviumnetworks.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; Narayana Prasad
> <narayanaprasad.athreya@caviumnetworks.com>; dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for
> inline protocol
> 
> Adding support for inline protocol processing
> 
> In ingress side, application will receive regular IP packets, without any IPsec
> related info. Application will do a selector check (SP-SA
> check) by making use of the metadata from the packet. The device-specific
> metadata in mbuf would aid in determing the security session which
> processed the packet.
> 
> In egress side, the plain packet would be submitted to the driver. The
> packet will have optional metadata, which could be used to identify the
> security session associated with the packet.
> 
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>

Akhil, Radu, could you review this patch?

Thanks,
Pablo

Re: [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol

[Akhil Goyal]

Reviewed-by: Akhil Goyal <akhil.goyal@nxp.com>

Re: [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol

[Nicolau, Radu]

> -----Original Message-----
> From: Anoob Joseph [mailto:anoob.joseph@caviumnetworks.com]
> Sent: Monday, December 18, 2017 7:15 AM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Doherty, Declan
> <declan.doherty@intel.com>; Nicolau, Radu <radu.nicolau@intel.com>;
> Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>
> Cc: Anoob Joseph <anoob.joseph@caviumnetworks.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; Narayana Prasad
> <narayanaprasad.athreya@caviumnetworks.com>; dev@dpdk.org
> Subject: [PATCH v6 2/2] examples/ipsec-secgw: add support for inline
> protocol
> 
> Adding support for inline protocol processing
> 
> In ingress side, application will receive regular IP packets, without any IPsec
> related info. Application will do a selector check (SP-SA
> check) by making use of the metadata from the packet. The device-specific
> metadata in mbuf would aid in determing the security session which
> processed the packet.
> 
> In egress side, the plain packet would be submitted to the driver. The packet
> will have optional metadata, which could be used to identify the security
> session associated with the packet.
> 
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
Acked-by: Radu Nicolau <radu.nicolau@intel.com>

Re: [dpdk-dev] [PATCH v6 0/2] add inline protocol support

[De Lara Guarch, Pablo]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Anoob Joseph
> Sent: Monday, December 18, 2017 7:15 AM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Doherty, Declan
> <declan.doherty@intel.com>; Nicolau, Radu <radu.nicolau@intel.com>;
> Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>
> Cc: Anoob Joseph <anoob.joseph@caviumnetworks.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; Narayana Prasad
> <narayanaprasad.athreya@caviumnetworks.com>; dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v6 0/2] add inline protocol support
> 
> The series adds inline protocol support in DPDK.
> 
> First patch introduces changes in lib to enable applications to save a (void
> *) pointer as "userdata" in security session. For inline processed packets,
> applications would use the metadata field in the mbuf
> (rte_mbuf.udata64) to retrieve the userdata registered for the security
> session which processed the packet. The metadata would be device specific.
> 
> This is primarily required for inline protocol processed ingress packets. For
> such packets, the packet may not have enough information to identify the
> security parameters with which the packet was processed.
> Application can register what it needs to identify the required parameter.
> The userdata will be set while creating the security session.
> 
> Second patch adds support for inline protocol in ipsec-secgw application
> 
> Anoob Joseph (2):
>   lib/security: add support for get userdata
>   examples/ipsec-secgw: add support for inline protocol
> 
>  doc/guides/prog_guide/rte_security.rst       |  22 ++++-
>  examples/ipsec-secgw/esp.c                   |   6 +-
>  examples/ipsec-secgw/ipsec-secgw.c           |  42 +++++++++-
>  examples/ipsec-secgw/ipsec.c                 | 121 ++++++++++++++++++++++-
> ----
>  lib/librte_security/rte_security.c           |  12 +++
>  lib/librte_security/rte_security.h           |  20 +++++
>  lib/librte_security/rte_security_driver.h    |  18 ++++
>  lib/librte_security/rte_security_version.map |   1 +
>  8 files changed, 219 insertions(+), 23 deletions(-)
> 
> --
> 2.7.4

Applied to dpdk-next-crypto.
Thanks,

Pablo