From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 932A07CBF for ; Wed, 26 Jul 2017 15:47:09 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2017 06:47:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,415,1496127600"; d="scan'208";a="1176640572" Received: from dwdohert-mobl1.ger.corp.intel.com (HELO [163.33.228.138]) ([163.33.228.138]) by fmsmga001.fm.intel.com with ESMTP; 26 Jul 2017 06:46:29 -0700 To: Akhil Goyal , dev@dpdk.org, borisp@mellanox.com References: <7834b3bd-0800-500c-1c89-3b89e2eb47fa@nxp.com> <20170725112153.29699-1-akhil.goyal@nxp.com> Cc: radu.nicolau@intel.com, aviadye@mellanox.com, sandeep.malik@nxp.com, hemant.agrawal@nxp.com, pablo.de.lara.guarch@intel.com From: Declan Doherty Message-ID: Date: Wed, 26 Jul 2017 14:46:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170725112153.29699-1-akhil.goyal@nxp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 13:47:10 -0000 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); On 25/07/2017 12:21 PM, Akhil Goyal wrote: > Below is a counter proposal for the RFC sent by Boris. > If we find some consensus, we can have implementation for this proposal in a few weeks. > > The proposal is largely inline with the thoughts from Declan with a few exceptions. > Here we are proposing a security framework which can be used both by crypto drivers > and the hw offloaded NIC to showcase the protocol offload support as well as inline > ipsec in hw offloaded NIC. > > The placement of the rte_security.X can either be a separate library like > lib/librte_security/ or it can be taken as an extension to the lib/librte_cryptodev/. > The reason for placing this in the cryptodev is that we are referring to some > crypto enums and the APIs look similar to that of cryptodev. > > Here we propose that the application may be able to configure either NIC or > crypto PMD to perform IPSec and other security operations. > This is configured using the API > > int > rte_security_configure(uint16_t dev_id, char *dev_name); > > This API take dev_id and dev_name to identify which device needs to perform security > operation. Once the device is enabled for Security operations, the application can > create and initialize the session for the enabled device. > > struct rte_security_session * > rte_security_session_create(struct rte_mempool *mempool); > > int > rte_security_session_init(uint16_t dev_id, char *dev_name, > struct rte_security_session *sess, > struct rte_security_sess_conf *conf, > struct rte_mempool *mempool); > > These two APIs are similar to the rte_cryptodev_sym_session_create and > rte_cryptodev_sym_session_init respectively, except that rte_security_session_init > takes device name also to identify between the NIC(IPSEC inline or full offload) > or crypto(look aside protocol offload). > > These sessions can be cleared and freed with the APIs > > int > rte_security_session_clear(uint8_t dev_id, char *dev_name, > struct rte_security_session *sess); > int > rte_security_session_free(struct rte_security_session *sess); > > The details for various structures used are mentioned in the below patch. > These are very similar to what Declan proposed with a few additions. > This can be updated further for other security protocols like MACSec and DTLS > > Now, after the application configures the session using above APIs, it needs to > attach the session with the crypto_op in case the session is configured for > crypto look aside protocol offload. For IPSec inline/ full protocol offload > using NIC, the mbuf ol_flags can be set as per the RFC suggested by Boris. > > Configuration path for both crypto and NIC can be illustrated as below > > Configuration Path Configuration Path > for NIC for Crypto > | | > +--------|--------+ +--------|--------+ > | Add/Remove | | Add/Remove | > | IPsec SA | | IPSec SA | > | | | | | | > |--------|--------| +--------|--------+ > | | > +--------V--------+ | > | Flow API | | > +--------|--------+ | > | | > +--------V--------+ +--------V--------+ > | | | | > | NIC PMD | | Crypto PMD | > | | | | > +--------|--------+ +--------|--------+ > | | > +--------|--------+ +--------|--------+ > | HW ACCELERATED | | HW Crypto | > | NIC | | Protocol Aware | > | | | 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 */ > }; > > > Egress Data Path > > For ETH_INLINE_CRYPTO For CRYPTO_PROTO_OFFLOAD > | | > +--------|--------+ +-----------|-----------+ > | egress IPsec | | Plain packet from NIC | > | | | | | | > | +------V------+ | | +--------V--------+ | > | | SABD lookup | | | | SA lookup | | > | +------|------+ | | +--------|--------+ | > | +------V------+ | | +--------V--------+ | > | | Tunnel | | | | session attach | | > | +------|------+ | | +--------|--------+ | +------------+ > | +------V------+ | | +--------V--------+ | | Hw crypto | > | | ESP | | | |Enqueue to crypto|------> Device | <--- Headers are added by the HW device. > | | | | | | Device | | | | > | +------|------+ | | +-----------------+ | +-----|------+ > +--------V--------+ | +-----------------+ | | > | | | Dequeue from |<-----------+ > +--------V--------+ | | Crypto Device | | > | L2 Stack | | +--------|--------+ | > +--------|--------+ | +--------V--------+ | > | | | L2 Stack | | > +--------V--------+ | +--------|--------+ | > | | +-----------|-----------+ > | NIC PMD | | > | | +-----------V-----------+ > +--------|--------+ | NIC PMD | > | | (packet sent out) | > +--------|--------+ +-----------|-----------+ > | HW ACCELERATED | > | NIC | > | | > +--------|--------+ > > Ingress Data Path > > For ETH_INLINE_CRYPTO For CRYPTO_PROTO_OFFLOAD > | | > +--------|--------+ +-----------|-----------+ > | Ingress ipsec | | Encap packet from NIC | > | | | | | | > | +------V------+ | | +--------V--------+ | > | | HW ACC NIC | | | | SA lookup | | > | +------|------+ | | +--------|--------+ | > | +------V------+ | | +--------V--------+ | > | |validate ESP | | | | session attach | | > | +------|------+ | | +--------|--------+ | +------------+ > | +------V------+ | | +--------V--------+ | | Hw crypto | > | |Remove ESP | | | |Enqueue to crypto|------> Device | <--- Headers are removed by the HW device. > | | and Tunnel | | | | Device | | | | > | +------|------+ | | +-----------------+ | +-----|------+ > +--------V--------+ | +-----------------+ | | > | | | Dequeue from |<-----------+ > +--------V----------+ | | Crypto Device | | > |Plain packet to App| | +--------|--------+ | > +--------|----------+ | +--------V--------+ | > | |Plain packet to | | > | | app | | > | +-----------------+ | > +-----------------------+ > > > Akhil Goyal (1): > RFC: rte_security: proposal > > lib/librte_security/rte_security.h | 405 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 405 insertions(+) > create mode 100644 lib/librte_security/rte_security.h >