From: Akhil Goyal <akhil.goyal@nxp.com>
To: Hemant Agrawal <hemant.agrawal@nxp.com>,
Declan Doherty <declan.doherty@intel.com>, <dev@dpdk.org>,
<borisp@mellanox.com>
Cc: <radu.nicolau@intel.com>, <aviadye@mellanox.com>,
<sandeep.malik@nxp.com>, <pablo.de.lara.guarch@intel.com>
Subject: Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload
Date: Thu, 3 Aug 2017 16:55:36 +0530 [thread overview]
Message-ID: <cf9d489a-d46b-1a40-a8fd-6ccafb1b2eeb@nxp.com> (raw)
In-Reply-To: <9c0b8bdd-2693-4275-664f-8ccf7b368031@nxp.com>
On 8/2/2017 6:46 PM, Hemant Agrawal wrote:
> Hi Declan,
>
> On 7/26/2017 7:16 PM, Declan Doherty wrote:
>> Hey Akhil, I like the proposal of allowing the rte_secruity API to be
>> supported on both NIC and crypto devices as I think it allows us to
>> cover all the protocol offload scenarios in a consist manner.
>>
>> The main concern I have is in regards to the device identification in a
>> consistent manner between device types, and I'm not exactly clear from
>> your description below on how you want to do that, as the dev_id and
>> port_id can overlap.
>>
>> If we follow this model, I think it would a good time to introduce a
>> sudo UUID into each device in DPDK, not necessarily a 16 byte UUID but I
>> think a unit16_t or uint32_t would be more than sufficient for DPDK
>> needs. As we now have a common rte_device structure in all device types,
>> we can add the UUID here, and then allow common APIs like this to use
>> the UUID as the key. We could also then support some generic device APIs
>> such as:
>>
>> uuid_t rte_device_get_uuid_by_name(char *dev_name);
>>
>> uuid_t rte_ethdev_get_port_uuid(uint8_t pid);
>> uuid_t rte_cryptodev_get_device_uuid(uint8_t pid);
>>
>> Which will allow easy retrieval handle to use in the rte_security APIs.
>>
>> Also I don't know if we need all the semantic of the cryptodev API in
>> regards the way sessions are managed as I these security sessions are
>> implicitly linked to hardware there isn't any need to support moving
>> session between devices?
>>
>> int rte_security_configure(uuid_t uuid, struct rte_mempool *mempool);
>>
>> struct rte_security_session *sess
>> rte_security_session_create(uuid_t uuid,
>> struct rte_security_sess_conf *conf);
>>
>
> Thanks for the comment. The uuid idea is good, we should work on it.
> But this work can be started without uuid as well. the port and platform
> type shall be able to help identifying the destination.
>
> We shall do it in next phase.
On another thought, we can do away with dev_name for the rte_security
APIs. rte_security APIs can configure crypto/NIC based on the
action_type which the application provides. If it uses
RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD, then crypto device is configured
else for other cases, it will configure NIC device.
>>> Now the application(ipsec-secgw) have 4 paths to decide for the data
>>> path.
>>> 1. Non-protocol offload (currently implemented)
>>> 2. IPSec inline(only crypto operations using NIC)
>>> 3. full protocol offload(crypto operations along with all the IPsec
>>> header
>>> and trailer processing using NIC)
>>> 4. look aside protocol offload(single-pass encryption and
>>> authentication with
>>> additional levels of protocol processing offload using crypto device)
>>>
>>> The application can decide using the below action types
>>> enum rte_security_session_action_type {
>>> RTE_SECURITY_SESS_ETH_INLINE_CRYPTO,
>>> /**< Crypto operations are performed by Network interface */
>>> RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD,
>>> /**< Crypto operations with protocol support are performed
>>> * by Network/ethernet device.
>>> */
>>> RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD,
>>> /**< Crypto operations with protocol support are performed
>>> * by Crypto device.
>>> */
>>> RTE_SECURITY_SESS_NONE
>>> /**< Non protocol offload. Application need to manage everything */
>>> };
>>>
Also there would be one more structure required to add the security
operations into rte_cryptodev or rte_eth_dev
struct rte_security_ops {
security_configure_session_t session_configure;
/**< Configure a Security session. */
security_free_session_t session_clear;
/**< Clear a security sessions private data. */
....
}
And the rte_security_capability can be added in the
rte_eth_dev_info/rte_cryptodev_info
- Akhil
next prev parent reply other threads:[~2017-08-03 11:25 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 7:35 [dpdk-dev] [RFC 0/7] ipsec inline Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 1/7] ethdev: add device ipsec encrypt/decrypt capability flags Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 2/7] ethdev: Add ESP header to generic flow steering Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 3/7] ethdev: add rte flow action for crypto Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 4/7] cryptodev: add ipsec xform Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 5/7] mbuf: Add IPsec crypto flags Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 6/7] mbuf: Added next_esp_proto field Boris Pismenny
2017-07-10 7:35 ` [dpdk-dev] [RFC 7/7] example/ipsec_gw: Support SA offload in datapath Boris Pismenny
2017-07-11 17:06 ` [dpdk-dev] [RFC 0/7] ipsec inline Declan Doherty
2017-07-12 14:08 ` Boris Pismenny
2017-07-14 11:12 ` Akhil Goyal
2017-07-25 11:21 ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Akhil Goyal
2017-07-25 11:21 ` [dpdk-dev] [RFC PATCH 1/1] rte_security: proposal Akhil Goyal
2017-07-26 13:46 ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Declan Doherty
2017-08-02 13:16 ` Hemant Agrawal
2017-08-03 11:25 ` Akhil Goyal [this message]
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH v2 0/4] " Akhil Goyal
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH 1/4] rte_security: API definitions Akhil Goyal
2017-08-15 11:04 ` Radu Nicolau
2017-08-16 7:39 ` Akhil Goyal
2017-08-16 15:40 ` Hemant Agrawal
2017-08-18 9:16 ` Thomas Monjalon
2017-08-18 12:20 ` Hemant Agrawal
2017-08-21 10:32 ` Boris Pismenny
2017-08-21 10:54 ` Akhil Goyal
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH 2/4] cryptodev: entend cryptodev to support security APIs Akhil Goyal
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH 3/4] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-08-15 6:35 ` [dpdk-dev] [RFC PATCH 4/4] example/ipsec-secgw: add support for offloading crypto op Akhil Goyal
2017-08-29 14:49 ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Thomas Monjalon
2017-08-31 9:37 ` Akhil Goyal
2017-08-31 10:06 ` Thomas Monjalon
2017-08-31 10:52 ` Akhil Goyal
2017-08-31 13:14 ` Thomas Monjalon
2017-08-31 14:09 ` Radu Nicolau
2017-09-06 15:53 ` Jerin Jacob
2017-09-08 11:12 ` Akhil Goyal
2017-09-11 18:10 ` Jerin Jacob
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=cf9d489a-d46b-1a40-a8fd-6ccafb1b2eeb@nxp.com \
--to=akhil.goyal@nxp.com \
--cc=aviadye@mellanox.com \
--cc=borisp@mellanox.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=radu.nicolau@intel.com \
--cc=sandeep.malik@nxp.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).