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
