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 A4B96A0487 for ; Tue, 30 Jul 2019 10:57:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7FDAD1BFE4; Tue, 30 Jul 2019 10:57:03 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 5B94D1BFD1 for ; Tue, 30 Jul 2019 10:57:02 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DCC8D21B34; Tue, 30 Jul 2019 04:57:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 30 Jul 2019 04:57:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=gsT8L8PKETayxxbbqnMSNEUNzGtDYs1i5sF3cgAq3H0=; b=EsCDJFWSQ5Av oUFwC7D2p8tTVC8s4y7ZYi1wSsL7M/8wzbTalagQNzh543CODaJgfOK/4xGD/ZT9 jsEMlXyFBd+vtmYJU63jLLkNYlD2Z3TLVUhREsLh55/lSgbVHXJ82pcYulPEuQbb gsg8gDpjeTUU9SCwOHc8NYgFC32rlyM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=gsT8L8PKETayxxbbqnMSNEUNzGtDYs1i5sF3cgAq3 H0=; b=X8bWlwjsC6uNdhWAY8YHCO+mSpIvGYSCo8WluEYFm9g/laKSDs/E+N3Q6 gDVOUIvuQgGrIgrO+qDVAp4CWUPFfiItF/fUCjNxZTAK4WBBC3/zRqhMo5z5lTxt 4nWKOZPxtfmJ29bEEEbmJJRBbvQ9dpJuzkw/Mlm4iH35i+dTDBRJ85TRpJP0MUNs S034ClSYyTGOe/q5ll4TnOYtQwUIM/KBMWz8WdZEqwQ4ziJkGWKV0blmni3YWILA zgH8h31zqOpqTqKpuCyzN9Dzub2z79Ap1qyo4SNK1HeABDj4KUSQgmmqqY5GAg23 wk6Xvo/GTijtjj3DsBSnsUFKvyBbw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrleefgddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 33F6980060; Tue, 30 Jul 2019 04:57:00 -0400 (EDT) From: Thomas Monjalon To: Akhil Goyal Cc: Bernard Iremonger , "dev@dpdk.org" , Anoob Joseph , "konstantin.ananyev@intel.com" , Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya Date: Tue, 30 Jul 2019 10:56:59 +0200 Message-ID: <2658214.f7z3ihukRQ@xps> In-Reply-To: References: <1562835937-24141-1-git-send-email-bernard.iremonger@intel.com> <2417926.RaMoeEf8dU@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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 in 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 it 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 performance > > > > > differences in the two code paths. Atleast on NXP platforms 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 library. > > > > > > 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 enhancements > > > are done thereafter. > > > Previously all IPSec related stuff was done in the application, > > > 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 previously > > > 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 change. > > > > 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 quality rules, > > I suggest to start a new git repository for it. > > OK got your point, but in that case, I would say, legacy code shall not be removed > Until we have the ipsec lib as experimental. > User should have both the code paths as long as we have ipsec library experimental. That's your take. When do you plan to remove experimental status of IPsec library?