[dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload

[Akhil Goyal]

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