* [dpdk-dev] [PATCH 0/2] add inline protocol support @ 2017-11-20 10:31 Anoob Joseph 2017-11-20 10:31 ` [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie Anoob Joseph ` (2 more replies) 0 siblings, 3 replies; 67+ messages in thread From: Anoob Joseph @ 2017-11-20 10:31 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy, Radu Nicolau Cc: Narayana Prasad, Jerin Jacob, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie 2017-11-20 10:31 [dpdk-dev] [PATCH 0/2] add inline protocol support Anoob Joseph @ 2017-11-20 10:31 ` Anoob Joseph 2017-11-20 12:12 ` Radu Nicolau 2017-11-20 10:31 ` [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Anoob Joseph 2 siblings, 1 reply; 67+ messages in thread From: Anoob Joseph @ 2017-11-20 10:31 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy, Radu Nicolau Cc: Narayana Prasad, Jerin Jacob, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie 2017-11-20 10:31 ` [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie Anoob Joseph @ 2017-11-20 12:12 ` Radu Nicolau 2017-11-20 15:32 ` Anoob 0 siblings, 1 reply; 67+ messages in thread From: Radu Nicolau @ 2017-11-20 12:12 UTC (permalink / raw) To: Anoob Joseph, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Narayana Prasad, Jerin Jacob, dev 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; ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie 2017-11-20 12:12 ` Radu Nicolau @ 2017-11-20 15:32 ` Anoob 2017-11-20 17:49 ` Radu Nicolau 0 siblings, 1 reply; 67+ messages in thread From: Anoob @ 2017-11-20 15:32 UTC (permalink / raw) To: Radu Nicolau, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Narayana Prasad, Jerin Jacob, dev 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; > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie 2017-11-20 15:32 ` Anoob @ 2017-11-20 17:49 ` Radu Nicolau 2017-11-20 19:09 ` Anoob Joseph 0 siblings, 1 reply; 67+ messages in thread From: Radu Nicolau @ 2017-11-20 17:49 UTC (permalink / raw) To: Anoob, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Narayana Prasad, Jerin Jacob, dev 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> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie 2017-11-20 17:49 ` Radu Nicolau @ 2017-11-20 19:09 ` Anoob Joseph 2017-11-21 10:15 ` Radu Nicolau 0 siblings, 1 reply; 67+ messages in thread From: Anoob Joseph @ 2017-11-20 19:09 UTC (permalink / raw) To: Radu Nicolau, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Narayana Prasad, Jerin Jacob, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie 2017-11-20 19:09 ` Anoob Joseph @ 2017-11-21 10:15 ` Radu Nicolau 0 siblings, 0 replies; 67+ messages in thread From: Radu Nicolau @ 2017-11-21 10:15 UTC (permalink / raw) To: Anoob Joseph, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Narayana Prasad, Jerin Jacob, dev 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 > ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add support for inline protocol 2017-11-20 10:31 [dpdk-dev] [PATCH 0/2] add inline protocol support Anoob Joseph 2017-11-20 10:31 ` [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie Anoob Joseph @ 2017-11-20 10:31 ` Anoob Joseph 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Anoob Joseph 2 siblings, 0 replies; 67+ messages in thread From: Anoob Joseph @ 2017-11-20 10:31 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy, Radu Nicolau Cc: Narayana Prasad, Jerin Jacob, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v2 0/2] add inline protocol support 2017-11-20 10:31 [dpdk-dev] [PATCH 0/2] add inline protocol support Anoob Joseph 2017-11-20 10:31 ` [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie Anoob Joseph 2017-11-20 10:31 ` [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph @ 2017-11-22 6:55 ` Anoob Joseph 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata Anoob Joseph ` (3 more replies) 2 siblings, 4 replies; 67+ messages in thread From: Anoob Joseph @ 2017-11-22 6:55 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Anoob Joseph @ 2017-11-22 6:55 ` Anoob Joseph 2017-11-22 11:29 ` Radu Nicolau 2017-11-22 13:27 ` Neil Horman 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph ` (2 subsequent siblings) 3 siblings, 2 replies; 67+ messages in thread From: Anoob Joseph @ 2017-11-22 6:55 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata Anoob Joseph @ 2017-11-22 11:29 ` Radu Nicolau 2017-11-22 11:52 ` Anoob 2017-11-22 13:27 ` Neil Horman 1 sibling, 1 reply; 67+ messages in thread From: Radu Nicolau @ 2017-11-22 11:29 UTC (permalink / raw) To: Anoob Joseph, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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. */ > }; ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata 2017-11-22 11:29 ` Radu Nicolau @ 2017-11-22 11:52 ` Anoob 2017-11-22 12:12 ` Radu Nicolau 0 siblings, 1 reply; 67+ messages in thread From: Anoob @ 2017-11-22 11:52 UTC (permalink / raw) To: Radu Nicolau, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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. */ >> }; > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata 2017-11-22 11:52 ` Anoob @ 2017-11-22 12:12 ` Radu Nicolau 0 siblings, 0 replies; 67+ messages in thread From: Radu Nicolau @ 2017-11-22 12:12 UTC (permalink / raw) To: Anoob, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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. */ >>> }; >> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata Anoob Joseph 2017-11-22 11:29 ` Radu Nicolau @ 2017-11-22 13:27 ` Neil Horman 2017-11-22 14:13 ` Anoob 1 sibling, 1 reply; 67+ messages in thread From: Neil Horman @ 2017-11-22 13:27 UTC (permalink / raw) To: Anoob Joseph Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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 > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata 2017-11-22 13:27 ` Neil Horman @ 2017-11-22 14:13 ` Anoob 2017-11-27 13:55 ` Neil Horman 0 siblings, 1 reply; 67+ messages in thread From: Anoob @ 2017-11-22 14:13 UTC (permalink / raw) To: Neil Horman Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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 >> >> ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata 2017-11-22 14:13 ` Anoob @ 2017-11-27 13:55 ` Neil Horman 0 siblings, 0 replies; 67+ messages in thread From: Neil Horman @ 2017-11-27 13:55 UTC (permalink / raw) To: Anoob Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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 > > > > > > > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: add support for inline protocol 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Anoob Joseph 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata Anoob Joseph @ 2017-11-22 6:55 ` Anoob Joseph 2017-11-22 12:21 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Nelio Laranjeiro 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 " Anoob Joseph 3 siblings, 0 replies; 67+ messages in thread From: Anoob Joseph @ 2017-11-22 6:55 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Anoob Joseph 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata Anoob Joseph 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph @ 2017-11-22 12:21 ` Nelio Laranjeiro 2017-11-22 12:55 ` Anoob 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 " Anoob Joseph 3 siblings, 1 reply; 67+ messages in thread From: Nelio Laranjeiro @ 2017-11-22 12:21 UTC (permalink / raw) To: Anoob Joseph Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support 2017-11-22 12:21 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Nelio Laranjeiro @ 2017-11-22 12:55 ` Anoob 2017-11-22 13:05 ` Nelio Laranjeiro 0 siblings, 1 reply; 67+ messages in thread From: Anoob @ 2017-11-22 12:55 UTC (permalink / raw) To: Nelio Laranjeiro Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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, > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support 2017-11-22 12:55 ` Anoob @ 2017-11-22 13:05 ` Nelio Laranjeiro 2017-11-22 13:38 ` Anoob 2017-11-22 15:13 ` Anoob 0 siblings, 2 replies; 67+ messages in thread From: Nelio Laranjeiro @ 2017-11-22 13:05 UTC (permalink / raw) To: Anoob Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support 2017-11-22 13:05 ` Nelio Laranjeiro @ 2017-11-22 13:38 ` Anoob 2017-11-22 13:53 ` Anoob 2017-11-22 15:13 ` Anoob 1 sibling, 1 reply; 67+ messages in thread From: Anoob @ 2017-11-22 13:38 UTC (permalink / raw) To: Nelio Laranjeiro Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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, >>> ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support 2017-11-22 13:38 ` Anoob @ 2017-11-22 13:53 ` Anoob 0 siblings, 0 replies; 67+ messages in thread From: Anoob @ 2017-11-22 13:53 UTC (permalink / raw) To: Nelio Laranjeiro Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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, >>>> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support 2017-11-22 13:05 ` Nelio Laranjeiro 2017-11-22 13:38 ` Anoob @ 2017-11-22 15:13 ` Anoob 2017-11-22 15:25 ` Nelio Laranjeiro 1 sibling, 1 reply; 67+ messages in thread From: Anoob @ 2017-11-22 15:13 UTC (permalink / raw) To: Nelio Laranjeiro Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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, >>> ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support 2017-11-22 15:13 ` Anoob @ 2017-11-22 15:25 ` Nelio Laranjeiro 0 siblings, 0 replies; 67+ messages in thread From: Nelio Laranjeiro @ 2017-11-22 15:25 UTC (permalink / raw) To: Anoob Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v3 0/2] add inline protocol support 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Anoob Joseph ` (2 preceding siblings ...) 2017-11-22 12:21 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Nelio Laranjeiro @ 2017-11-23 11:19 ` Anoob Joseph 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata Anoob Joseph ` (2 more replies) 3 siblings, 3 replies; 67+ messages in thread From: Anoob Joseph @ 2017-11-23 11:19 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 " Anoob Joseph @ 2017-11-23 11:19 ` Anoob Joseph 2017-11-24 8:50 ` Akhil Goyal 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 0/2] add inline protocol support Anoob Joseph 2 siblings, 1 reply; 67+ messages in thread From: Anoob Joseph @ 2017-11-23 11:19 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata Anoob Joseph @ 2017-11-24 8:50 ` Akhil Goyal 2017-11-24 9:39 ` Radu Nicolau 0 siblings, 1 reply; 67+ messages in thread From: Akhil Goyal @ 2017-11-24 8:50 UTC (permalink / raw) To: Anoob Joseph, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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. */ > }; > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 8:50 ` Akhil Goyal @ 2017-11-24 9:39 ` Radu Nicolau 2017-11-24 10:55 ` Akhil Goyal 0 siblings, 1 reply; 67+ messages in thread From: Radu Nicolau @ 2017-11-24 9:39 UTC (permalink / raw) To: Akhil Goyal, Anoob Joseph, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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. */ >> }; >> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 9:39 ` Radu Nicolau @ 2017-11-24 10:55 ` Akhil Goyal 2017-11-24 11:17 ` Radu Nicolau 0 siblings, 1 reply; 67+ messages in thread From: Akhil Goyal @ 2017-11-24 10:55 UTC (permalink / raw) To: Radu Nicolau, Anoob Joseph, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 10:55 ` Akhil Goyal @ 2017-11-24 11:17 ` Radu Nicolau 2017-11-24 11:34 ` Akhil Goyal 0 siblings, 1 reply; 67+ messages in thread From: Radu Nicolau @ 2017-11-24 11:17 UTC (permalink / raw) To: Akhil Goyal, Anoob Joseph, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 11:17 ` Radu Nicolau @ 2017-11-24 11:34 ` Akhil Goyal 2017-11-24 11:59 ` Radu Nicolau 2017-11-24 12:22 ` Anoob 0 siblings, 2 replies; 67+ messages in thread From: Akhil Goyal @ 2017-11-24 11:34 UTC (permalink / raw) To: Radu Nicolau, Anoob Joseph, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 11:34 ` Akhil Goyal @ 2017-11-24 11:59 ` Radu Nicolau 2017-11-24 12:03 ` Akhil Goyal 2017-11-24 12:22 ` Anoob 1 sibling, 1 reply; 67+ messages in thread From: Radu Nicolau @ 2017-11-24 11:59 UTC (permalink / raw) To: Akhil Goyal, Anoob Joseph, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 11:59 ` Radu Nicolau @ 2017-11-24 12:03 ` Akhil Goyal 2017-12-06 7:30 ` Anoob 0 siblings, 1 reply; 67+ messages in thread From: Akhil Goyal @ 2017-11-24 12:03 UTC (permalink / raw) To: Radu Nicolau, Anoob Joseph, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 12:03 ` Akhil Goyal @ 2017-12-06 7:30 ` Anoob 2017-12-06 9:43 ` Radu Nicolau 0 siblings, 1 reply; 67+ messages in thread From: Anoob @ 2017-12-06 7:30 UTC (permalink / raw) To: Akhil Goyal, Radu Nicolau, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-12-06 7:30 ` Anoob @ 2017-12-06 9:43 ` Radu Nicolau 2017-12-11 7:21 ` Anoob 0 siblings, 1 reply; 67+ messages in thread From: Radu Nicolau @ 2017-12-06 9:43 UTC (permalink / raw) To: Anoob, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 >> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-12-06 9:43 ` Radu Nicolau @ 2017-12-11 7:21 ` Anoob 2017-12-12 8:55 ` Akhil Goyal 0 siblings, 1 reply; 67+ messages in thread From: Anoob @ 2017-12-11 7:21 UTC (permalink / raw) To: Radu Nicolau, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 >>> >> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-12-11 7:21 ` Anoob @ 2017-12-12 8:55 ` Akhil Goyal 2017-12-12 13:50 ` Anoob Joseph 0 siblings, 1 reply; 67+ messages in thread From: Akhil Goyal @ 2017-12-12 8:55 UTC (permalink / raw) To: Anoob, Radu Nicolau, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 >>>> >>> >> > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-12-12 8:55 ` Akhil Goyal @ 2017-12-12 13:50 ` Anoob Joseph 2017-12-13 14:38 ` Akhil Goyal 0 siblings, 1 reply; 67+ messages in thread From: Anoob Joseph @ 2017-12-12 13:50 UTC (permalink / raw) To: Akhil Goyal, Radu Nicolau, Declan Doherty, Sergio Gonzalez Monroy Cc: anoob.joseph, Jerin Jacob, Narayana Prasad, dev 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 >>>>> >>>> >>> >> >> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-12-12 13:50 ` Anoob Joseph @ 2017-12-13 14:38 ` Akhil Goyal 0 siblings, 0 replies; 67+ messages in thread From: Akhil Goyal @ 2017-12-13 14:38 UTC (permalink / raw) To: Anoob Joseph, Radu Nicolau, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 >>>>>> >>>>> >>>> >>> >>> >> > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 11:34 ` Akhil Goyal 2017-11-24 11:59 ` Radu Nicolau @ 2017-11-24 12:22 ` Anoob 2017-11-29 5:43 ` Anoob 2017-12-04 9:28 ` Akhil Goyal 1 sibling, 2 replies; 67+ messages in thread From: Anoob @ 2017-11-24 12:22 UTC (permalink / raw) To: Akhil Goyal, Radu Nicolau, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 12:22 ` Anoob @ 2017-11-29 5:43 ` Anoob 2017-12-04 9:28 ` Akhil Goyal 1 sibling, 0 replies; 67+ messages in thread From: Anoob @ 2017-11-29 5:43 UTC (permalink / raw) To: Akhil Goyal, Radu Nicolau, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-11-24 12:22 ` Anoob 2017-11-29 5:43 ` Anoob @ 2017-12-04 9:28 ` Akhil Goyal 2017-12-04 10:16 ` Anoob 1 sibling, 1 reply; 67+ messages in thread From: Akhil Goyal @ 2017-12-04 9:28 UTC (permalink / raw) To: Anoob, Radu Nicolau, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata 2017-12-04 9:28 ` Akhil Goyal @ 2017-12-04 10:16 ` Anoob 0 siblings, 0 replies; 67+ messages in thread From: Anoob @ 2017-12-04 10:16 UTC (permalink / raw) To: Akhil Goyal, Radu Nicolau, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 >> >> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add support for inline protocol 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 " Anoob Joseph 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata Anoob Joseph @ 2017-11-23 11:19 ` Anoob Joseph 2017-12-11 11:02 ` Radu Nicolau 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 0/2] add inline protocol support Anoob Joseph 2 siblings, 1 reply; 67+ messages in thread From: Anoob Joseph @ 2017-11-23 11:19 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add support for inline protocol 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph @ 2017-12-11 11:02 ` Radu Nicolau 0 siblings, 0 replies; 67+ messages in thread From: Radu Nicolau @ 2017-12-11 11:02 UTC (permalink / raw) To: Anoob Joseph, Akhil Goyal, Declan Doherty, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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> ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v4 0/2] add inline protocol support 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 " Anoob Joseph 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata Anoob Joseph 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph @ 2017-12-15 8:30 ` Anoob Joseph 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 1/2] lib/security: add support for get userdata Anoob Joseph ` (2 more replies) 2 siblings, 3 replies; 67+ messages in thread From: Anoob Joseph @ 2017-12-15 8:30 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v4 1/2] lib/security: add support for get userdata 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 0/2] add inline protocol support Anoob Joseph @ 2017-12-15 8:30 ` Anoob Joseph 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 0/2] add inline protocol support Anoob Joseph 2 siblings, 0 replies; 67+ messages in thread From: Anoob Joseph @ 2017-12-15 8:30 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v4 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 0/2] add inline protocol support Anoob Joseph 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 1/2] lib/security: add support for get userdata Anoob Joseph @ 2017-12-15 8:30 ` Anoob Joseph 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 0/2] add inline protocol support Anoob Joseph 2 siblings, 0 replies; 67+ messages in thread From: Anoob Joseph @ 2017-12-15 8:30 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v5 0/2] add inline protocol support 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 0/2] add inline protocol support Anoob Joseph 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 1/2] lib/security: add support for get userdata Anoob Joseph 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph @ 2017-12-15 8:43 ` Anoob Joseph 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata Anoob Joseph ` (2 more replies) 2 siblings, 3 replies; 67+ messages in thread From: Anoob Joseph @ 2017-12-15 8:43 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 0/2] add inline protocol support Anoob Joseph @ 2017-12-15 8:43 ` Anoob Joseph 2017-12-15 10:01 ` Akhil Goyal 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support Anoob Joseph 2 siblings, 1 reply; 67+ messages in thread From: Anoob Joseph @ 2017-12-15 8:43 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata Anoob Joseph @ 2017-12-15 10:01 ` Akhil Goyal 2017-12-15 10:53 ` Anoob Joseph 0 siblings, 1 reply; 67+ messages in thread From: Akhil Goyal @ 2017-12-15 10:01 UTC (permalink / raw) To: Anoob Joseph, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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: *; > }; > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata 2017-12-15 10:01 ` Akhil Goyal @ 2017-12-15 10:53 ` Anoob Joseph 2017-12-15 10:58 ` Akhil Goyal 0 siblings, 1 reply; 67+ messages in thread From: Anoob Joseph @ 2017-12-15 10:53 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: anoob.joseph, Jerin Jacob, Narayana Prasad, dev 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: *; >> }; >> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata 2017-12-15 10:53 ` Anoob Joseph @ 2017-12-15 10:58 ` Akhil Goyal 0 siblings, 0 replies; 67+ messages in thread From: Akhil Goyal @ 2017-12-15 10:58 UTC (permalink / raw) To: Anoob Joseph, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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: *; >>> }; >>> >> > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 0/2] add inline protocol support Anoob Joseph 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata Anoob Joseph @ 2017-12-15 8:43 ` Anoob Joseph 2017-12-15 9:39 ` Nelio Laranjeiro 2017-12-15 10:04 ` Akhil Goyal 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support Anoob Joseph 2 siblings, 2 replies; 67+ messages in thread From: Anoob Joseph @ 2017-12-15 8:43 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph @ 2017-12-15 9:39 ` Nelio Laranjeiro 2017-12-15 11:03 ` Anoob Joseph 2017-12-15 10:04 ` Akhil Goyal 1 sibling, 1 reply; 67+ messages in thread From: Nelio Laranjeiro @ 2017-12-15 9:39 UTC (permalink / raw) To: Anoob Joseph Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-15 9:39 ` Nelio Laranjeiro @ 2017-12-15 11:03 ` Anoob Joseph 2017-12-15 13:35 ` Nelio Laranjeiro 0 siblings, 1 reply; 67+ messages in thread From: Anoob Joseph @ 2017-12-15 11:03 UTC (permalink / raw) To: Nelio Laranjeiro Cc: anoob.joseph, Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-15 11:03 ` Anoob Joseph @ 2017-12-15 13:35 ` Nelio Laranjeiro 0 siblings, 0 replies; 67+ messages in thread From: Nelio Laranjeiro @ 2017-12-15 13:35 UTC (permalink / raw) To: Anoob Joseph Cc: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-12-15 9:39 ` Nelio Laranjeiro @ 2017-12-15 10:04 ` Akhil Goyal 2017-12-15 11:16 ` Anoob Joseph 1 sibling, 1 reply; 67+ messages in thread From: Akhil Goyal @ 2017-12-15 10:04 UTC (permalink / raw) To: Anoob Joseph, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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; > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-15 10:04 ` Akhil Goyal @ 2017-12-15 11:16 ` Anoob Joseph 0 siblings, 0 replies; 67+ messages in thread From: Anoob Joseph @ 2017-12-15 11:16 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: anoob.joseph, Jerin Jacob, Narayana Prasad, dev 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; >> > ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v6 0/2] add inline protocol support 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 0/2] add inline protocol support Anoob Joseph 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata Anoob Joseph 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph @ 2017-12-18 7:15 ` Anoob Joseph 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata Anoob Joseph ` (2 more replies) 2 siblings, 3 replies; 67+ messages in thread From: Anoob Joseph @ 2017-12-18 7:15 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support Anoob Joseph @ 2017-12-18 7:15 ` Anoob Joseph 2017-12-18 7:34 ` Akhil Goyal 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2018-01-09 16:05 ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support De Lara Guarch, Pablo 2 siblings, 1 reply; 67+ messages in thread From: Anoob Joseph @ 2017-12-18 7:15 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata Anoob Joseph @ 2017-12-18 7:34 ` Akhil Goyal 0 siblings, 0 replies; 67+ messages in thread From: Akhil Goyal @ 2017-12-18 7:34 UTC (permalink / raw) To: Anoob Joseph, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev 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> ^ permalink raw reply [flat|nested] 67+ messages in thread
* [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support Anoob Joseph 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata Anoob Joseph @ 2017-12-18 7:15 ` Anoob Joseph 2018-01-08 16:10 ` De Lara Guarch, Pablo ` (2 more replies) 2018-01-09 16:05 ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support De Lara Guarch, Pablo 2 siblings, 3 replies; 67+ messages in thread From: Anoob Joseph @ 2017-12-18 7:15 UTC (permalink / raw) To: Akhil Goyal, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Anoob Joseph, Jerin Jacob, Narayana Prasad, dev 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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph @ 2018-01-08 16:10 ` De Lara Guarch, Pablo 2018-01-09 9:12 ` Akhil Goyal 2018-01-16 11:00 ` Nicolau, Radu 2 siblings, 0 replies; 67+ messages in thread From: De Lara Guarch, Pablo @ 2018-01-08 16:10 UTC (permalink / raw) To: Anoob Joseph, Akhil Goyal, Doherty, Declan, Nicolau, Radu, Gonzalez Monroy, Sergio Cc: Jerin Jacob, Narayana Prasad, dev > -----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 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2018-01-08 16:10 ` De Lara Guarch, Pablo @ 2018-01-09 9:12 ` Akhil Goyal 2018-01-16 11:00 ` Nicolau, Radu 2 siblings, 0 replies; 67+ messages in thread From: Akhil Goyal @ 2018-01-09 9:12 UTC (permalink / raw) To: Anoob Joseph, Declan Doherty, Radu Nicolau, Sergio Gonzalez Monroy Cc: Jerin Jacob, Narayana Prasad, dev Reviewed-by: Akhil Goyal <akhil.goyal@nxp.com> ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2018-01-08 16:10 ` De Lara Guarch, Pablo 2018-01-09 9:12 ` Akhil Goyal @ 2018-01-16 11:00 ` Nicolau, Radu 2 siblings, 0 replies; 67+ messages in thread From: Nicolau, Radu @ 2018-01-16 11:00 UTC (permalink / raw) To: Anoob Joseph, Akhil Goyal, Doherty, Declan, Gonzalez Monroy, Sergio Cc: Jerin Jacob, Narayana Prasad, dev > -----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> ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [dpdk-dev] [PATCH v6 0/2] add inline protocol support 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support Anoob Joseph 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata Anoob Joseph 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph @ 2018-01-09 16:05 ` De Lara Guarch, Pablo 2 siblings, 0 replies; 67+ messages in thread From: De Lara Guarch, Pablo @ 2018-01-09 16:05 UTC (permalink / raw) To: Anoob Joseph, Akhil Goyal, Doherty, Declan, Nicolau, Radu, Gonzalez Monroy, Sergio Cc: Jerin Jacob, Narayana Prasad, dev > -----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 ^ permalink raw reply [flat|nested] 67+ messages in thread
end of thread, other threads:[~2018-01-16 11:01 UTC | newest] Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-20 10:31 [dpdk-dev] [PATCH 0/2] add inline protocol support Anoob Joseph 2017-11-20 10:31 ` [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie Anoob Joseph 2017-11-20 12:12 ` Radu Nicolau 2017-11-20 15:32 ` Anoob 2017-11-20 17:49 ` Radu Nicolau 2017-11-20 19:09 ` Anoob Joseph 2017-11-21 10:15 ` Radu Nicolau 2017-11-20 10:31 ` [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Anoob Joseph 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata Anoob Joseph 2017-11-22 11:29 ` Radu Nicolau 2017-11-22 11:52 ` Anoob 2017-11-22 12:12 ` Radu Nicolau 2017-11-22 13:27 ` Neil Horman 2017-11-22 14:13 ` Anoob 2017-11-27 13:55 ` Neil Horman 2017-11-22 6:55 ` [dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-11-22 12:21 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Nelio Laranjeiro 2017-11-22 12:55 ` Anoob 2017-11-22 13:05 ` Nelio Laranjeiro 2017-11-22 13:38 ` Anoob 2017-11-22 13:53 ` Anoob 2017-11-22 15:13 ` Anoob 2017-11-22 15:25 ` Nelio Laranjeiro 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 " Anoob Joseph 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata Anoob Joseph 2017-11-24 8:50 ` Akhil Goyal 2017-11-24 9:39 ` Radu Nicolau 2017-11-24 10:55 ` Akhil Goyal 2017-11-24 11:17 ` Radu Nicolau 2017-11-24 11:34 ` Akhil Goyal 2017-11-24 11:59 ` Radu Nicolau 2017-11-24 12:03 ` Akhil Goyal 2017-12-06 7:30 ` Anoob 2017-12-06 9:43 ` Radu Nicolau 2017-12-11 7:21 ` Anoob 2017-12-12 8:55 ` Akhil Goyal 2017-12-12 13:50 ` Anoob Joseph 2017-12-13 14:38 ` Akhil Goyal 2017-11-24 12:22 ` Anoob 2017-11-29 5:43 ` Anoob 2017-12-04 9:28 ` Akhil Goyal 2017-12-04 10:16 ` Anoob 2017-11-23 11:19 ` [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-12-11 11:02 ` Radu Nicolau 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 0/2] add inline protocol support Anoob Joseph 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 1/2] lib/security: add support for get userdata Anoob Joseph 2017-12-15 8:30 ` [dpdk-dev] [PATCH v4 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 0/2] add inline protocol support Anoob Joseph 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata Anoob Joseph 2017-12-15 10:01 ` Akhil Goyal 2017-12-15 10:53 ` Anoob Joseph 2017-12-15 10:58 ` Akhil Goyal 2017-12-15 8:43 ` [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2017-12-15 9:39 ` Nelio Laranjeiro 2017-12-15 11:03 ` Anoob Joseph 2017-12-15 13:35 ` Nelio Laranjeiro 2017-12-15 10:04 ` Akhil Goyal 2017-12-15 11:16 ` Anoob Joseph 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support Anoob Joseph 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata Anoob Joseph 2017-12-18 7:34 ` Akhil Goyal 2017-12-18 7:15 ` [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph 2018-01-08 16:10 ` De Lara Guarch, Pablo 2018-01-09 9:12 ` Akhil Goyal 2018-01-16 11:00 ` Nicolau, Radu 2018-01-09 16:05 ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support De Lara Guarch, Pablo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).