[dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add target queues in flow actions

[Anoob]

Hi Nelio,

Since support of RSS with inline crypto/protocol is hardware 
implementation dependent, it would be better if there is some sort of 
capability check before setting the flow parameters in the application.

If the hardware doesn't support RSS with inline processing, then the RSS 
flow action will have to be ignored in the driver. This wouldn't look 
right from application's point of view. And also the PMD would need 
application-specific logic to handle such cases, which may not scale well.

Thanks,
Anoob


On 11/23/2017 08:42 PM, Nelio Laranjeiro wrote:
> Mellanox INNOVA NIC needs to have final target queue actions to perform
> inline crypto.
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro at 6wind.com>
> ---
>   examples/ipsec-secgw/ipsec.c | 27 ++++++++++++++++++++++++++-
>   examples/ipsec-secgw/ipsec.h |  2 +-
>   2 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index 17bd7620d..e967f88b3 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -142,6 +142,22 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   							rte_eth_dev_get_sec_ctx(
>   							sa->portid);
>   			const struct rte_security_capability *sec_cap;
> +			uint8_t rss_key[40];
> +			struct rte_eth_rss_conf rss_conf = {
> +				.rss_key = rss_key,
> +				.rss_key_len = 40,
> +			};
> +			struct rte_eth_dev *eth_dev;
> +			union {
> +				struct rte_flow_action_rss rss;
> +				struct {
> +					const struct rte_eth_rss_conf *rss_conf;
> +					uint16_t num;
> +					uint16_t queue[RTE_MAX_QUEUES_PER_PORT];
> +				} local;
> +			} action_rss;
> +			unsigned int i;
> +			unsigned int j;
>   
>   			sa->sec_session = rte_security_session_create(ctx,
>   					&sess_conf, ipsec_ctx->session_pool);
> @@ -201,7 +217,16 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   			sa->action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
>   			sa->action[0].conf = sa->sec_session;
>   
> -			sa->action[1].type = RTE_FLOW_ACTION_TYPE_END;
> +			sa->action[1].type = RTE_FLOW_ACTION_TYPE_RSS;
> +			sa->action[1].conf = &action_rss;
> +			eth_dev = ctx->device;
> +			rte_eth_dev_rss_hash_conf_get(sa->portid, &rss_conf);
> +			for (i = 0, j = 0; i < eth_dev->data->nb_rx_queues; ++i)
> +				if (eth_dev->data->rx_queues[i])
> +					action_rss.local.queue[j++] = i;
> +			action_rss.local.num = j;
> +			action_rss.local.rss_conf = &rss_conf;
> +			sa->action[2].type = RTE_FLOW_ACTION_TYPE_END;
>   
>   			sa->attr.egress = (sa->direction ==
>   					RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
> diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
> index 775b316ff..82ffc1c6d 100644
> --- a/examples/ipsec-secgw/ipsec.h
> +++ b/examples/ipsec-secgw/ipsec.h
> @@ -133,7 +133,7 @@ struct ipsec_sa {
>   	uint32_t ol_flags;
>   
>   #define MAX_RTE_FLOW_PATTERN (4)
> -#define MAX_RTE_FLOW_ACTIONS (2)
> +#define MAX_RTE_FLOW_ACTIONS (4)
>   	struct rte_flow_item pattern[MAX_RTE_FLOW_PATTERN];
>   	struct rte_flow_action action[MAX_RTE_FLOW_ACTIONS];
>   	struct rte_flow_attr attr;