[dpdk-dev] [PATCH v4 06/12] ethdev: support security APIs
Shahaf Shuler
shahafs at mellanox.com
Sun Oct 15 15:13:15 CEST 2017
Hi Akhil,
Sunday, October 15, 2017 1:17 AM, Akhil Goyal:
> From: Declan Doherty <declan.doherty at intel.com>
>
> rte_flow_action type and ethdev updated to support rte_security sessions
> for crypto offload to ethernet device.
>
> Signed-off-by: Boris Pismenny <borisp at mellanox.com>
> Signed-off-by: Aviad Yehezkel <aviadye at mellanox.com>
> Signed-off-by: Radu Nicolau <radu.nicolau at intel.com>
> Signed-off-by: Declan Doherty <declan.doherty at intel.com>
> ---
> lib/librte_ether/rte_ethdev.c | 11 +++++++++++
> lib/librte_ether/rte_ethdev.h | 18 ++++++++++++++++--
> lib/librte_ether/rte_ethdev_version.map | 1 +
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index 0b1e928..9520f1e 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -301,6 +301,17 @@ rte_eth_dev_socket_id(uint16_t port_id)
> return rte_eth_devices[port_id].data->numa_node;
> }
>
> +void *
> +rte_eth_dev_get_sec_ctx(uint8_t port_id) {
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, NULL);
> +
> + if (rte_eth_devices[port_id].data->dev_flags &
> RTE_ETH_DEV_SECURITY)
> + return rte_eth_devices[port_id].data->security_ctx;
> +
> + return NULL;
> +}
> +
> uint16_t
> rte_eth_dev_count(void)
> {
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index aaf02b3..159bb73 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -180,6 +180,8 @@ extern "C" {
> #include <rte_dev.h>
> #include <rte_devargs.h>
> #include <rte_errno.h>
> +#include <rte_common.h>
> +
> #include "rte_ether.h"
> #include "rte_eth_ctrl.h"
> #include "rte_dev_info.h"
> @@ -379,7 +381,8 @@ struct rte_eth_rxmode {
> * This bit is temporary till rxmode bitfield offloads API will
> * be deprecated.
> */
> - ignore_offload_bitfield : 1;
> + ignore_offload_bitfield : 1,
> + enable_sec : 1; /**< Enable security offload */
I suggest to keep the ignore_offload_bitfield last.
Also you should update the convert function. See:
rte_eth_convert_rx_offload_bitfield
rte_eth_convert_rx_offloads
> };
>
> /**
> @@ -707,8 +710,10 @@ struct rte_eth_txmode {
> /**< If set, reject sending out tagged pkts */
> hw_vlan_reject_untagged : 1,
> /**< If set, reject sending out untagged pkts */
> - hw_vlan_insert_pvid : 1;
> + hw_vlan_insert_pvid : 1,
> /**< If set, enable port based VLAN insertion */
> + enable_sec : 1;
> + /**< Enable security offload */
Am copying the comment and answer from v2 on the Tx offload. Seems like we agreed, why it is not addressed?
From: Radu Nicolau radu.nicolau at intel.com
> Already comment on it in the previous version [1].
> I don't think there is a justification to introduce new approach to set Tx offloads given there is already patch set which provides such new API [2].
> I think this patch should be on top of it.
I agree with you, that is if the new offload API will be merged we will
also change this one. But until then it makes testing and developing
more difficult.
> };
>
> /**
> @@ -969,6 +974,7 @@ struct rte_eth_conf { #define
> DEV_RX_OFFLOAD_VLAN (DEV_RX_OFFLOAD_VLAN_STRIP | \
> DEV_RX_OFFLOAD_VLAN_FILTER | \
> DEV_RX_OFFLOAD_VLAN_EXTEND)
> +#define DEV_RX_OFFLOAD_SECURITY 0x00000100
>
> /**
> * TX offload capabilities of a device.
> @@ -998,6 +1004,7 @@ struct rte_eth_conf {
> * When set application must guarantee that per-queue all mbufs comes
> from
> * the same mempool and has refcnt = 1.
> */
> +#define DEV_TX_OFFLOAD_SECURITY 0x00008000
>
> struct rte_pci_device;
>
> @@ -1736,6 +1743,9 @@ struct rte_eth_dev {
> enum rte_eth_dev_state state; /**< Flag indicating the port state */
> } __rte_cache_aligned;
>
> +void *
> +rte_eth_dev_get_sec_ctx(uint8_t port_id);
> +
> struct rte_eth_dev_sriov {
> uint8_t active; /**< SRIOV is active with 16, 32 or 64 pools */
> uint8_t nb_q_per_pool; /**< rx queue number per pool */
> @@ -1796,6 +1806,8 @@ struct rte_eth_dev_data {
> int numa_node; /**< NUMA node connection */
> struct rte_vlan_filter_conf vlan_filter_conf;
> /**< VLAN filter configuration. */
> + void *security_ctx;
> + /**< Context for security ops */
> };
>
> /** Device supports hotplug detach */
> @@ -1806,6 +1818,8 @@ struct rte_eth_dev_data { #define
> RTE_ETH_DEV_BONDED_SLAVE 0x0004
> /** Device supports device removal interrupt */
> #define RTE_ETH_DEV_INTR_RMV 0x0008
> +/** Device supports inline security processing */
> +#define RTE_ETH_DEV_SECURITY 0x0010
I have to insist about this one. I don't understand which extra functionality it provides in compare to the DEV_RX_OFFLOAD_SECURITY or DEV_TX_OFFLOAD_SECURITY.
Answer from previous version was to "allow to advertise that a device has security features without the need to check exactly which ones are they".
I think this is exactly what DEV_RX_OFFLOAD_SECURITY and DEV_TX_OFFLOAD_SECURITY means. Those flags does not provide the full capabilities of the different security offload supported by the device (those should be queried through rte_scurity APIs).
>
> /**
> * @internal
> diff --git a/lib/librte_ether/rte_ethdev_version.map
> b/lib/librte_ether/rte_ethdev_version.map
> index e27f596..3cc6a64 100644
> --- a/lib/librte_ether/rte_ethdev_version.map
> +++ b/lib/librte_ether/rte_ethdev_version.map
> @@ -194,5 +194,6 @@ DPDK_17.11 {
> rte_eth_dev_pool_ops_supported;
> rte_eth_dev_reset;
> rte_flow_error_set;
> + rte_eth_dev_get_sec_ctx;
>
> } DPDK_17.08;
> --
> 2.9.3
More information about the dev
mailing list