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

[Anoob]

Hi Nelio,

Please see inline.

Thanks,

Anoob


On 11/29/2017 06:20 PM, Nelio Laranjeiro wrote:
> Hi Anoob,
>
> On Wed, Nov 29, 2017 at 06:00:38PM +0530, Anoob wrote:
>>     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.
> There is a real issue here, RTE_FLOW API needs a terminal action, security is
> not one [1] you must have one of the followings: QUEUE, DROP, RSS, PF,
> VF or PASSTHRU.
>
> Flow API does not work with "capabilities" as the application can verify
> the rule using the validate().  If it cannot be validated the
> application can test another kind of rule until the PMD returns a
> success.
>
> Here, I am proposing the RSS as RSS with a single queue is equivalent to queue.
>
> On Mellanox NIC we need the RSS or QUEUE in ingress and for Egress PASSTHRU
> is good.
>
> What are your needs?
Thanks for the clarification. Understood the issue here. On Cavium 
hardware SECURITY will be terminating. So a better approach would be to 
first check from the application (using rte_flow_verify()) if SECURITY 
is terminating action. If it fails, then application can do RSS/QUEUE. 
That should solve the issue.
>
> Regards,
>
>>     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 [1]<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;
>>
>> References
>>
>>     Visible links
>>     1. mailto:nelio.laranjeiro at 6wind.com
> [1] http://dpdk.org/doc/guides/prog_guide/rte_flow.html?highlight=rte_flow#actions
>