From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Anoob Joseph <anoobj@marvell.com>,
Akhil Goyal <akhil.goyal@nxp.com>,
"Iremonger, Bernard" <bernard.iremonger@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
dpdk-techboard <techboard@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: set default
Date: Mon, 18 Nov 2019 13:03:12 +0000 [thread overview]
Message-ID: <SN6PR11MB255841B381A276E2C7FFA0089A4D0@SN6PR11MB2558.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MN2PR18MB287732671A8E5139A166F660DF790@MN2PR18MB2877.namprd18.prod.outlook.com>
> > > > > > > >
> > > > > > > > 11/10/2019 14:40, Akhil Goyal:
> > > > > > > > > Hi All,
> > > > > > > > >
> > > > > > > > > This patchset would need ack from more vendors as it will
> > > > > > > > > impact user
> > > > > > > > experience
> > > > > > > > > on a key example application which is normally
> > > > > > > > > demonstrated to
> > > > > > > customers.
> > > > > > > > >
> > > > > > > > > IPSec library is still evolving and there are new
> > > > > > > > > functionality added every
> > > > > > > > release.
> > > > > > > > > Atleast from NXP side we are not OK with this change.
> > > > > > > >
> > > > > > > > What can be changed in the library to make it acceptable as
> > > > > > > > a default in this example?
> > > > > > > >
> > > > > > >
> > > > > > > We are observing performance issues with ipsec library. So
> > > > > > > would request other Vendors to confirm if they are OK with the
> > > > > > > performance
> > > > > numbers.
> > > > > >
> > > > > > Could you give some details on the performance issues you are seeing.
> > > > > >
> > > > >
> > > > > We were observing about 4-5% drop when using the ipsec-lib instead
> > > > > of the Legacy code path. We would again measure it on RC1. That is
> > > > > why I say, I will Hold this patch till RC2, unless some other vendor also
> > confirms that.
> > > >
> > > > Is there any update on performance measurements on 19.11-rc1 ?
> > > >
> > > The performance impact of this patch is huge ~10% w.r.t. 19.11-rc1 base on
> > NXP hardware.
> > >
> > > We cannot merge this. Anoob also reported performance issues on Marvell
> > hardware.
> >
> > Sure, 10% is a lot, so more than understandable.
> > Though, I think we do need to decide our future goals for it.
> > I see two main options here:
> > 1. Make lib code-path on par with legacy one in terms of performance,
> > deprecate and then remove legacy code-path.
> > Till that happen (deprecation/removal) to minimize code divergence,
> > forbid to add new features to legacy code path only.
> > New features should be added to both paths, or library code path.
> > Obviously that one looks like a preferred option to me, but it requires some
> > effort from all interested parties (Intel, NXP, Marvell, ...).
> > If everyone is ok with it, then I think it would be good to have some draft
> > timeline here.
> > If you guys are not interested in this effort, then the only other approach I can
> > think about:
>
> [Anoob] I would say this is the right option. But then, there are features getting added only to lib ipsec mode. There are features like
> "fallback session" or anti replay which is only added for lib ipsec mode and not for non lib ipsec mode. Such features are good to have
> but would cost extra cycles in the datapath. Since it is only added for lib ipsec mode, the perf divergence between lib ipsec mode and
> non lib ipsec mode is fairly obvious.
AFAIK, all these features are optional and can be disabled.
For performance comparison, I'd expect we run lib mode with extra features disabled.
>
> So what is the solution? Both the modes need to be at par if our end strategy is going to deprecate one. If we need to reach a state
> where we can do apples to apples comparison, new features should be added to both modes and there should be a consensus on the
> feature implementations.
>
> Also, looking at the "fallback session" feature, the feature was "pushed" without properly addressing the issues. The solution was
> hardly suitable for inline ipsec and the comments were ignored. Marvell is not ok with adding checks in datapath for an incomplete
> feature. Marvell withdrew the objections when it was conveyed that the review comments were deemed invaluable. Also because it
> was added to lib ipsec path which is not being used currently for our benchmarks. Marvell will be submitting an RFC for supporting
> fallback session with few changes in the rte_security library. When we attempt that, we can take care of only non lib ipsec mode as lib
> ipsec mode already has one and Marvell cannot work on two different fronts, when the other contributors themselves don't care
> about other established modes.
>
> Also considering that lib ipsec is under constant change, (and is still experimental), I would not be too excited about making it the
> default immediately. I see that there are usages supported by the non lib ipsec mode, which is not supported by lib ipsec mode.
>
> For example, ipv4 & ipv6 using same SPI is valid for non lib ipsec, but not for lib ipsec. Because of this, the default conf doesn't even
> run when launched with lib ipsec mode. I'm not sure whether we should rush with making it the default when the whole idea is still
> "experimental".
>
> > 2. split ipsec-secgw app into 2 (one using librte_ipsec, second using raw devices
> > (legacy one)).
> > We probably can still try to keep some code shared by 2 apps:
> > (configuration/initialization/session management (SAD, SPD)),
> > but actual packet processing path will be different.
> > I really don't like that option, but I think we need to come-up with clear
> > decision, one way or another.
> >
> > Thanks
> > Konstantin
> >
> >
> >
> >
> >
next prev parent reply other threads:[~2019-11-18 13:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 8:59 [dpdk-dev] [PATCH 0/2] " Bernard Iremonger
2019-08-29 8:59 ` [dpdk-dev] [PATCH 1/2] examples/ipsec-secgw: set default to IPsec library mode Bernard Iremonger
2019-09-26 13:47 ` Ananyev, Konstantin
2019-09-26 13:51 ` Iremonger, Bernard
2019-08-29 8:59 ` [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add -l 0 parameter to old scripts Bernard Iremonger
2019-09-26 13:43 ` Ananyev, Konstantin
2019-09-26 13:46 ` Iremonger, Bernard
2019-10-01 15:17 ` [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: set default Bernard Iremonger
2019-10-01 17:30 ` Ananyev, Konstantin
2019-10-02 8:59 ` Iremonger, Bernard
2019-10-02 9:11 ` Ananyev, Konstantin
2019-10-11 12:40 ` Akhil Goyal
2019-10-11 15:13 ` Iremonger, Bernard
2019-10-11 15:23 ` Thomas Monjalon
2019-10-15 6:42 ` Akhil Goyal
2019-10-15 8:54 ` Iremonger, Bernard
2019-10-15 15:05 ` Akhil Goyal
2019-10-16 10:44 ` Ananyev, Konstantin
2019-10-30 9:29 ` Iremonger, Bernard
2019-11-01 13:19 ` Akhil Goyal
2019-11-04 15:24 ` Ananyev, Konstantin
2019-11-05 8:01 ` Akhil Goyal
2019-11-05 9:10 ` Ananyev, Konstantin
2019-11-06 13:55 ` Anoob Joseph
2019-11-18 13:03 ` Ananyev, Konstantin [this message]
2019-10-16 4:18 ` Anoob Joseph
2019-10-01 15:17 ` [dpdk-dev] [PATCH v2 1/3] examples/ipsec-secgw: set default to IPsec library mode Bernard Iremonger
2019-10-14 13:53 ` Nicolau, Radu
2019-10-01 15:17 ` [dpdk-dev] [PATCH v2 2/3] examples/ipsec-secgw: add -l 0 parameter to old scripts Bernard Iremonger
2019-10-01 17:28 ` Ananyev, Konstantin
2019-10-14 13:55 ` Nicolau, Radu
2019-10-01 15:18 ` [dpdk-dev] [PATCH v2 3/3] examples/ipsec-secgw: update pktest.sh script Bernard Iremonger
2019-10-01 17:29 ` Ananyev, Konstantin
2019-10-14 13:56 ` 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=SN6PR11MB255841B381A276E2C7FFA0089A4D0@SN6PR11MB2558.namprd11.prod.outlook.com \
--to=konstantin.ananyev@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=anoobj@marvell.com \
--cc=bernard.iremonger@intel.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=techboard@dpdk.org \
--cc=thomas@monjalon.net \
/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).