From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B9CD9A10DA for ; Wed, 31 Jul 2019 12:20:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DB7781BF12; Wed, 31 Jul 2019 12:20:00 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 9491E1BF11 for ; Wed, 31 Jul 2019 12:19:58 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2019 03:19:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,329,1559545200"; d="scan'208";a="177265272" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga006.jf.intel.com with ESMTP; 31 Jul 2019 03:19:55 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX102.ger.corp.intel.com ([169.254.2.59]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 11:19:54 +0100 From: "Ananyev, Konstantin" To: Akhil Goyal , Thomas Monjalon CC: "Iremonger, Bernard" , "dev@dpdk.org" , Anoob Joseph , Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya Thread-Topic: [dpdk-dev] [EXT] [PATCH] doc: deprecate legacy code path in ipsec-secgw Thread-Index: AQHVRiuUahjna7FP7EWKTttMwp/2XKbimaGAgAAUtQCAAAL6gIAACY0AgAAPIgCAAAJkgIAAAbeAgAAVFwCAAA1RAIABZjBg Date: Wed, 31 Jul 2019 10:19:53 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580168A6002C@irsmsx105.ger.corp.intel.com> References: <1562835937-24141-1-git-send-email-bernard.iremonger@intel.com> <2417926.RaMoeEf8dU@xps> <2658214.f7z3ihukRQ@xps> <2601191342CEEE43887BDE71AB9772580168A5F46A@irsmsx105.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWMwYTRkMWYtMmY2OS00OTMwLWE0ZDgtZDE1YmUyMzcyNjM5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVHhQWTlHcWxvN2RROXpzYSsrM3RHTXB5WHl4MWlkZ0pTVnBnR01tdkJyTFBXaGt6YWowNk04R24zNDFZN1BQWSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [EXT] [PATCH] doc: deprecate legacy code path in ipsec-secgw X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Akhil, > > > > > > > > 30/07/2019 10:48, Akhil Goyal: > > > > > > 30/07/2019 09:20, Akhil Goyal: > > > > > > > > 30/07/2019 07:55, Akhil Goyal: > > > > > > > > > > > > > All the functionality of the legacy code path in = now available > > > > > > > > > > > > > in the librte_ipsec library. > > > > > > > > > > > > > It is planned to deprecate the legacy code path i= n the 19.11 > > > > > > > > > > > > > release and remove the legacy code path in the 20= .02 > > release. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Bernard Iremonger > > > > > > > > > > > > > > > > > Acked-by: Konstantin Ananyev > > > > > > > > > > > > > > > Acked-by: Fan Zhang > > > > > > > > > > > > > Acked-by: Akhil Goyal > > > > > > > > > > > > > --- > > > > > > > > > > > > > doc/guides/rel_notes/deprecation.rst | 5 +++++ > > > > > > > > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > > > > > > > > > > > > > > > > Acked-by: Anoob Joseph > > > > > > > > > > > > > > > > > > > > > > Applied to dpdk-next-crypto > > > > > > > > > > > > > > > > > > > > Why do we have a deprecation notice for some code path = in an > > > > example? > > > > > > > > > > The deprecation notices are for the API. > > > > > > > > > > > > > > > > > > > > I think you can drop the legacy code in 19.11, > > > > > > > > > > and I don't merge this patch in master. > > > > > > > > > > > > > > > > > > We are planning to remove the original code and replace i= t with > > IPSec > > > > > > > > > library APIs which are still experimental. > > > > > > > > > With this change there won't be any example of the legacy= ipsec > > code > > > > path. > > > > > > > > > > > > That's good to drop old code. > > > > > > If someone still wants to look at it, it is in old releases. > > > > > > > > > > > > > > > Applications over DPDK take ipsec-secgw as an example and= IPSec > > > > > > > > > is a major use case for customers. There may also be perf= ormance > > > > > > > > > differences in the two code paths. Atleast on NXP platfor= ms I saw > > > > > > > > > 5-7% drop when the patches were originally submitted. > > > > > > > > > Not sure what is the current state. > > > > > > > > > > > > That's a different issue you need to solve in the library. > > > > > > > > > > > > > > > I feel it is worth notifying the users that the original = codepath is > > > > > > > > > getting deprecated, so that they can plan to move to new = IPSec > > APIs. > > > > > > > > > > > > I hope they already planned to move when they saw the new libra= ry. > > > > > > > > > > > > > > The deprecation notice is not the right place for a change = in an > > example. > > > > > > > > What change is there in IPsec API? In which release? > > > > > > > > > > > > > > IPSec lib was introduced in 1902 release and a few enhancemen= ts > > > > > > > are done thereafter. > > > > > > > Previously all IPSec related stuff was done in the applicatio= n, > > > > > > > now we have IPSec Lib which perform similar work. > > > > > > > There are changes both in datapath as well as control path. > > > > > > > User need to adapt to the recent changes, as we may no longer > > > > > > > support/maintain the datapath/control path which was done pre= viously > > > > > > > and there may be some conflict. > > > > > > > > > > > > So the real DPDK change is to have a new library in 19.02. > > > > > > > > > > > > > If deprecation notice is not the right place, > > > > > > > then where should it be notified before actually making the c= hange. > > > > > > > > > > > > It has already been notified in "New Features" of 19.02 > > > > > > that there is an IPsec library. What do you want to notify more= ? > > > > > > Again, the example is not supposed to be a real application. > > > > > > If you want to maintain an IPsec application with better qualit= y rules, > > > > > > I suggest to start a new git repository for it. > > > > > > > > > > OK got your point, but in that case, I would say, legacy code sha= ll not be > > > > removed > > > > > Until we have the ipsec lib as experimental. > > > > > User should have both the code paths as long as we have ipsec lib= rary > > > > experimental. > > > > Not sure why it is needed? > There is some performance gap. Ok, and you think that keeping legacy code-path till 20.02 will provide enough time to analyze the perf drop for NXP devices? > Original Idea for ipsec lib was to have > better performing APIs. Not only. Main reasons were to hide from user complexity of IPsec packet processing and avoid necessity for each user to re-implement it.=20 Also legacy code doesn't provide many important features (replay window, ESN, multi-seg support, etc.) > How much gain is observed using these APIs on intel? It depends. >From my last observations for inline case library code-path is 10-15% faster than legacy one. Though I think reason for that in not in the librar= y itself, but that legacy code handles inline traffic in suboptimal way. For lookaside - in most cases library and legacy code performance is about = the same, except the case when we have a burst of packets where each packet belongs t= o different SA. In that case new code-path is 3-5% slower. As I understand, main reason is again not the library itself, but that in new code we try to group packets that belongs=20 to the same SA both before and after crypto-dev enqueue/dequeue. Usually that helps, but for that case it just adds extra overhead (no group= ing is possible).=20 > Do we have data? Atleast on NXP devices, these are not performing better. >=20 > > Why DPDK sample app can't use DPDK experimental API as it is, > > without some alternate code-path? >=20 > Sample app can use experimental APIs as is. There is no issue with that. > The intent is just to notify the users that it will be removed so that th= ey > can be ready for change in their code. Ok, but if we don't submit deprecation notice (as Thomas suggested)=20 how they'll be notified? Would there be a separate RN when we'll remove experimental tag and legacy code?=20 >=20 > > > > > > > > > > That's your take. > > > > When do you plan to remove experimental status of IPsec library? > > > > > > > There have been addition of some functionality in this release cycle.= I would > > say we > > > can wait for 1 release cycle for some fixes or changes which may be r= equired. > > > If it looks stable in next release cycle, we can make formal in DPDK = 2002. > > > > If we'll leave legacy code in 19.11, does it mean we'll have to > > support it for next 2 years (LTS cycle)? >=20 > The original intent of this patch was also to remove the legacy code in 2= 002 release and > not in 1911. Moreover, it is the application code that we need to remove.= We can get that patch > backported to the 19.11.1 release as well. Then it would be same. >=20