From: Anoob Joseph <anoob.joseph@caviumnetworks.com>
To: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Cc: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>,
Radu Nicolau <radu.nicolau@intel.com>,
dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v4 3/3] examples/ipsec-secgw: add Egress flow actions
Date: Fri, 15 Dec 2017 21:09:00 +0530 [thread overview]
Message-ID: <f65fbef7-afd5-6f2c-b1b9-f7764d62a2e3@caviumnetworks.com> (raw)
In-Reply-To: <20171215135300.zm6ubao24qqxstpl@laranjeiro-vm.dev.6wind.com>
Hi Nelio,
On 15-12-2017 19:23, Nelio Laranjeiro wrote:
> Hi Anoob,
>
> On Fri, Dec 15, 2017 at 02:35:12PM +0530, Anoob Joseph wrote:
>> Hi Nelio,
>>
>> On 12/14/2017 08:44 PM, Nelio Laranjeiro wrote:
>>> Add Egress flow create for devices supporting
>>> RTE_SECURITY_TX_HW_TRAILER_OFFLOAD.
>>>
>>> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>>> ---
>>> examples/ipsec-secgw/ipsec.c | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
>>> index 8e8dc6df7..d49970ad8 100644
>>> --- a/examples/ipsec-secgw/ipsec.c
>>> +++ b/examples/ipsec-secgw/ipsec.c
>>> @@ -201,6 +201,7 @@ 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);
>>> @@ -253,6 +254,13 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>>> &err);
>>> if (ret)
>>> goto flow_create_failure;
>>> + } else if (sa->attr.egress &&
>>> + (sa->ol_flags &
>>> + RTE_SECURITY_TX_HW_TRAILER_OFFLOAD)) {
>> If this flag is not set, the following code won't be executed, but it would
>> still try to create the flow.
> Right, with actions Security + END as the original code.
>
>> And if the flow create fails in that case then create_session would fail.
> Do you mean the original code is also wrong?
I would say it's not handling all the cases. Just like how we finalized
the ingress, egress might also need some work. Or may be we can retain
the original behavior with this patch and take up this issue separately.
>
>> I would suggest moving the flow_create also into the block (for
>> ingress and egress). Or may be initialize the flow with
>> actions END+END+END, and add SECURITY+<RSS/QUEUE/PASSTHRU>+END as it hits
>> various conditions. I'm not sure what the flow_create would do for such an
>> action. This would look ugly in any case. See if you get any better ideas!
> I think this comment is related to second patch where the
> "sa->action[1].type = RTE_FLOW_ACTION_TYPE_END;" is wrongly removed.
>
> Can you confirm before I send a new revision?
No. I was suggesting an alternate algorithm to handle the situation when
egress may/may not create flow while ingress would need flow by default.
What I suggested is something like this,
sa->action[0].type = RTE_FLOW_ACTION_TYPE_END;
sa->action[1].type = RTE_FLOW_ACTION_TYPE_END;
sa->action[2].type = RTE_FLOW_ACTION_TYPE_END;
if (ingress) {
sa->action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
...
} else if (egress && FLAG_ENABLED) {
sa->action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
...
}
flow_create();
On second thought, this may not work well. Another suggestion is,
if (ingress) {
sa->action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
...
flow_create();
} else if (egress && FLAG_ENABLED) {
sa->action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
...
flow_create();
}
// Here if flow_create fails, create_session should fail.
// Either flow or metadata flag is required
if (sa->flow == NULL && !(NEEDS_METADATA)) {
return -1;
}
>
>>> + sa->action[1].type =
>>> + RTE_FLOW_ACTION_TYPE_PASSTHRU;
>>> + sa->action[2].type =
>>> + RTE_FLOW_ACTION_TYPE_END;
>>> }
>>> flow_create:
>>> sa->flow = rte_flow_create(sa->portid,
> Thanks,
>
next prev parent reply other threads:[~2017-12-15 15:39 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
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 [this message]
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=f65fbef7-afd5-6f2c-b1b9-f7764d62a2e3@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).