From mboxrd@z Thu Jan 1 00:00:00 1970 From: Akhil Goyal Subject: Re: [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Date: Thu, 3 Aug 2017 16:55:36 +0530 Message-ID: References: <7834b3bd-0800-500c-1c89-3b89e2eb47fa@nxp.com> <20170725112153.29699-1-akhil.goyal@nxp.com> <9c0b8bdd-2693-4275-664f-8ccf7b368031@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: , , , To: Hemant Agrawal , Declan Doherty , , Return-path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0047.outbound.protection.outlook.com [104.47.32.47]) by dpdk.org (Postfix) with ESMTP id 2245E11D4 for ; Thu, 3 Aug 2017 13:25:46 +0200 (CEST) In-Reply-To: <9c0b8bdd-2693-4275-664f-8ccf7b368031@nxp.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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