From: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
To: Anoob Joseph <anoob.joseph@caviumnetworks.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 17:53:52 +0100 [thread overview]
Message-ID: <20171215165352.htocozxulv74e6xc@laranjeiro-vm.dev.6wind.com> (raw)
In-Reply-To: <f65fbef7-afd5-6f2c-b1b9-f7764d62a2e3@caviumnetworks.com>
Hi Anoob,
Seems you want to address a lot of stuff where is should be done in
a different series, please see below,
On Fri, Dec 15, 2017 at 09:09:00PM +0530, Anoob Joseph wrote:
> 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.
It is better to not mix everything, the final work can be done after.
> > > 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,
The default behavior of this function for
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO is to call a flow in both side
Ingress and Egress. Default behavior coded in main repository in this
file [1].
This series is only adding final actions to respect the generic flow
API.
> 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;
An END is final independently of what is after, as the extra actions are
only handled in their respective if branches, no need to initialize
everything to 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;
> }
This patch scope is done to respect generic flow API calls for
RTE_SECURITY_TX_HW_TRAILER_OFFLOAD devices as written in the commit log.
For RTE_SECURITY_TX_OLOAD_NEED_MDATA devices, it should be handled in a
separate patch/series, the default behavior is maintained for them.
> > > > + 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,
> >
>
Thanks,
[1] https://dpdk.org/browse/dpdk/tree/examples/ipsec-secgw/ipsec.c#n132
--
Nélio Laranjeiro
6WIND
next prev parent reply other threads:[~2017-12-15 16:53 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
2017-12-15 16:53 ` Nelio Laranjeiro [this message]
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=20171215165352.htocozxulv74e6xc@laranjeiro-vm.dev.6wind.com \
--to=nelio.laranjeiro@6wind.com \
--cc=anoob.joseph@caviumnetworks.com \
--cc=dev@dpdk.org \
--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).