From: Anoob Joseph <anoob.joseph@caviumnetworks.com>
To: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Cc: anoob.joseph@caviumnetworks.com,
Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>,
Radu Nicolau <radu.nicolau@intel.com>,
dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
Date: Wed, 13 Dec 2017 12:11:18 +0530 [thread overview]
Message-ID: <047cadcf-13dc-5368-4ad5-a27ff25c42f8@caviumnetworks.com> (raw)
In-Reply-To: <20171212143800.ggdtdfnbknttr45g@laranjeiro-vm.dev.6wind.com>
Hi Nelio,
On 12/12/2017 08:08 PM, Nelio Laranjeiro wrote:
> Hi Anoob,
>
> On Tue, Dec 12, 2017 at 07:34:31PM +0530, Anoob Joseph wrote:
>> Hi Nelio,
>>
>>
>> On 12/12/2017 07:14 PM, Nelio Laranjeiro wrote:
>>> Hi Anoob,
>>>
>>> On Tue, Dec 12, 2017 at 06:13:08PM +0530, Anoob Joseph wrote:
>>>> Hi Nelio,
>>>>
>>>>
>>>> On 12/11/2017 07:34 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@6wind.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v3:
>>>>>
>>>>> * removed PASSTHRU test for ingress.
>>>>> * removed check on configured queues for the queue action.
>>>>>
>>>>> Changes in v2:
>>>>>
>>>>> * Test the rule by PASSTHRU/RSS/QUEUE and apply the first one validated.
>>>>> ---
>>>>> examples/ipsec-secgw/ipsec.c | 57 ++++++++++++++++++++++++++++++++++++++++++--
>>>>> examples/ipsec-secgw/ipsec.h | 2 +-
>>>>> 2 files changed, 56 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
>>>>> index 17bd7620d..1b8b251c8 100644
>>>>> --- a/examples/ipsec-secgw/ipsec.c
>>>>> +++ b/examples/ipsec-secgw/ipsec.c
>>>>> @@ -142,6 +142,7 @@ 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;
>>>>> + int ret = 0;
>>>>> sa->sec_session = rte_security_session_create(ctx,
>>>>> &sess_conf, ipsec_ctx->session_pool);
>>>>> @@ -201,15 +202,67 @@ 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->attr.egress = (sa->direction ==
>>>>> RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
>>>>> sa->attr.ingress = (sa->direction ==
>>>>> RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
>>>>> + if (sa->attr.ingress) {
>>>>> + 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->action[2].type = RTE_FLOW_ACTION_TYPE_END;
>>>>> + /* Try RSS. */
>>>>> + 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;
>>>>> + ret = rte_flow_validate(sa->portid, &sa->attr,
>>>>> + sa->pattern, sa->action,
>>>>> + &err);
>>>>> + if (!ret)
>>>>> + goto flow_create;
>>>>> + /* Try Queue. */
>>>>> + sa->action[1].type = RTE_FLOW_ACTION_TYPE_QUEUE;
>>>>> + sa->action[1].conf =
>>>>> + &(struct rte_flow_action_queue){
>>>>> + .index = 0,
>>>>> + };
>>>>> + ret = rte_flow_validate(sa->portid, &sa->attr,
>>>>> + sa->pattern, sa->action,
>>>>> + &err);
>>>>> + if (ret)
>>>>> + goto flow_create_failure;
>>>>> + } else {
>>>>> + sa->action[1].type =
>>>>> + RTE_FLOW_ACTION_TYPE_PASSTHRU;
>>>>> + sa->action[2].type = RTE_FLOW_ACTION_TYPE_END;
>>>> We would need flow validate here also. And, for egress, the application will
>>>> be able to set metadata (set_pkt_metadata API) per packet. So flow may not
>>>> be required for such cases. But if the flow create fails, the session create
>>>> would also fail. It might be better if we check whether the PMD would need
>>>> metadata (part of the sec_cap->ol_flags).
>>> Seems what you are describing is outside of this scope which is only
>>> related to correctly implement the generic flow API with terminal
>>> actions.
>> Since SECURITY+PASSTHRU won't be terminal, this code segment might be
>> misleading.
> Well, I don't mind adding an extra verification even if the create
> should fail if the validate fails, as there is no other option it
> is just like adding another if statement considering the validate()
> cannot guarantee the flow will be created(), other errors like ENOMEM
> are still possible in the creation stage.
Good point. I was thinking of a scenario when flow for egress itself
would be optional.
>
>>> I'll suggest to add it in another patch.
>>>
>>> Anyway, the flow validate is useful in the ingress to select the best
>>> behavior RSS/Queue, if the flow validate may fail, the flow create
>>> should also fail for the same reasons.
>>>
>>>> If the driver doesn't need metadata and the flow create fails, then
>>>> the create session should fail. Any thoughts?
>>> How the create_session() can fail without having all the informations
>>> (pattern, metadata, ...) the application wants to offload?
>> Is flow mandatory for the egress traffic? My understanding is, it's not.
>> "set_pkt_metadata" API gives application the ability to do the lookup and
>> pass the info along with the packet. In such cases, flow creation is not
>> necessary.
> Some NIC need to apply a flow rule for Egress and they don't need
> metadata for the packet.
Understood. In that case, what I proposed could be a separate patch. The
ingress path is proper with this patch, but we can keep egress open for
improvements.
>
>> I do agree that this is outside the scope of this patch, but I was just
>> curious about the behavior since you touched the topic.
>>>>> + }
>>>>> +flow_create:
>>>>> sa->flow = rte_flow_create(sa->portid,
>>>>> &sa->attr, sa->pattern, sa->action, &err);
>>>>> if (sa->flow == NULL) {
>>>>> +flow_create_failure:
>>>>> RTE_LOG(ERR, IPSEC,
>>>>> "Failed to create ipsec flow msg: %s\n",
>>>>> err.message);
>>>>> diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
>>>>> index 775b316ff..3c367d392 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 (3)
>>>>> struct rte_flow_item pattern[MAX_RTE_FLOW_PATTERN];
>>>>> struct rte_flow_action action[MAX_RTE_FLOW_ACTIONS];
>>>>> struct rte_flow_attr attr;
>>> Thanks,
> Regards,
>
next prev parent reply other threads:[~2017-12-13 6:41 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 15:12 [dpdk-dev] [PATCH 1/2] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2017-11-23 15:12 ` [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-11-29 12:30 ` Anoob
2017-11-29 12:50 ` Nelio Laranjeiro
2017-11-30 10:46 ` Anoob
2017-11-30 12:28 ` Nelio Laranjeiro
2017-12-01 15:04 ` Anoob Joseph
2017-12-01 16:26 ` Nelio Laranjeiro
2017-12-04 14:11 ` [dpdk-dev] [PATCH v2 1/2] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2017-12-11 11:50 ` Radu Nicolau
2017-12-04 14:11 ` [dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-12-07 9:47 ` Anoob
2017-12-07 12:22 ` Nelio Laranjeiro
2017-12-08 14:00 ` Anoob
2017-12-08 14:40 ` Nelio Laranjeiro
2017-12-08 16:40 ` Anoob Joseph
2017-12-11 8:21 ` Nelio Laranjeiro
2017-12-11 9:00 ` Anoob
2017-12-11 14:04 ` [dpdk-dev] [PATCH v3 1/2] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2017-12-12 7:14 ` Anoob Joseph
2017-12-11 14:04 ` [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-12-12 12:43 ` Anoob Joseph
2017-12-12 13:44 ` Nelio Laranjeiro
2017-12-12 14:04 ` Anoob Joseph
2017-12-12 14:38 ` Nelio Laranjeiro
2017-12-13 6:41 ` Anoob Joseph [this message]
2017-12-13 10:02 ` Nelio Laranjeiro
2017-12-13 11:38 ` Anoob Joseph
2017-12-13 12:53 ` Nelio Laranjeiro
2017-12-13 13:53 ` Anoob Joseph
2017-12-13 14:47 ` Nelio Laranjeiro
2017-12-20 16:19 ` Boris Pismenny
2017-12-21 8:06 ` Anoob Joseph
2017-12-21 10:12 ` Boris Pismenny
2017-12-21 14:22 ` Adrien Mazarguil
2018-01-05 6:18 ` Anoob Joseph
2018-01-09 12:48 ` Nelio Laranjeiro
2018-01-10 6:21 ` Anoob Joseph
2018-01-05 5:52 ` Anoob Joseph
2017-12-14 15:14 ` [dpdk-dev] [PATCH v4 1/3] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2017-12-14 15:14 ` [dpdk-dev] [PATCH v4 2/3] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-12-18 8:23 ` Anoob Joseph
2017-12-18 9:57 ` Nélio Laranjeiro
2017-12-14 15:14 ` [dpdk-dev] [PATCH v4 3/3] examples/ipsec-secgw: add Egress " Nelio Laranjeiro
2017-12-15 9:05 ` Anoob Joseph
2017-12-15 13:53 ` Nelio Laranjeiro
2017-12-15 15:39 ` Anoob Joseph
2017-12-15 16:53 ` Nelio Laranjeiro
2017-12-15 17:01 ` Anoob Joseph
2017-12-18 10:24 ` [dpdk-dev] [PATCH v5 1/3] examples/ipsec-secgw: fix missing ingress flow attribute Nelio Laranjeiro
2018-01-18 14:50 ` De Lara Guarch, Pablo
2017-12-18 10:24 ` [dpdk-dev] [PATCH v5 2/3] examples/ipsec-secgw: add target queues in flow actions Nelio Laranjeiro
2017-12-19 6:22 ` Anoob Joseph
2017-12-18 10:24 ` [dpdk-dev] [PATCH v5 3/3] examples/ipsec-secgw: add Egress " Nelio Laranjeiro
2018-01-08 16:13 ` De Lara Guarch, Pablo
2018-01-16 16:12 ` Nicolau, Radu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=047cadcf-13dc-5368-4ad5-a27ff25c42f8@caviumnetworks.com \
--to=anoob.joseph@caviumnetworks.com \
--cc=dev@dpdk.org \
--cc=nelio.laranjeiro@6wind.com \
--cc=radu.nicolau@intel.com \
--cc=sergio.gonzalez.monroy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).