From: Radu Nicolau <radu.nicolau@intel.com>
To: Akhil Goyal <akhil.goyal@nxp.com>,
Anoob Joseph <anoob.joseph@caviumnetworks.com>,
Declan Doherty <declan.doherty@intel.com>,
Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
Narayana Prasad <narayanaprasad.athreya@caviumnetworks.com>,
dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata
Date: Fri, 24 Nov 2017 09:39:21 +0000 [thread overview]
Message-ID: <414c3491-7a54-09b4-0cde-a21bffaeb1ab@intel.com> (raw)
In-Reply-To: <fe1edabc-1593-436c-fcf2-caa0188862e1@nxp.com>
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. */
>> };
>>
>
next prev parent reply other threads:[~2017-11-24 9:39 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=414c3491-7a54-09b4-0cde-a21bffaeb1ab@intel.com \
--to=radu.nicolau@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=anoob.joseph@caviumnetworks.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=narayanaprasad.athreya@caviumnetworks.com \
--cc=sergio.gonzalez.monroy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).