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 > > > > > > > > > > > > > > > in the > > 19.11 > > > > > > > > > > > > > > > release and remove the legacy code path in the > > > > > > > > > > > > > > > 20.02 > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Bernard Iremonger > > > > > > <bernard.iremon...@intel.com> > > > > > > > > > > > > > > > Acked-by: Konstantin Ananyev > > > > <konstantin.anan...@intel.com> > > > > > > > > > > > > > > > Acked-by: Fan Zhang <roy.fan.zh...@intel.com> > > > > > > > > > > > > > > > Acked-by: Akhil Goyal <akhil.go...@nxp.com> > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > doc/guides/rel_notes/deprecation.rst | 5 +++++ > > > > > > > > > > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Acked-by: Anoob Joseph <ano...@marvell.com> > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > 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? > > Yes. We cannot commit for 19.11 timeframe to fix the performance issues in > the new code. You can send the patches, we can try our best to incorporate it > in > 19.11 but we cannot commit at this moment.
Ok, then let's put 20.02 as a preliminary target for removal experimental tag and legacy code-path. As you said, we can later consider to backport ipsec-secgw changes into 19.11.1 or so. Konstantin > > > > > > 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. > > 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 library > > 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 to > > 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 > > 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 > > grouping is > > possible). > > > > > Do we have data? Atleast on NXP devices, these are not performing better. > > > > > > > Why DPDK sample app can't use DPDK experimental API as it is, > > > > without some alternate code-path? > > > > > > 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 > > > they > > > can be ready for change in their code. > > > > Ok, but if we don't submit deprecation notice (as Thomas suggested) > > how they'll be notified? > As Thomas said, there is no need for sending the deprecation notice for > application. > So I have to hold my comment back. > > > Would there be a separate RN when we'll remove experimental tag > > and legacy code? > There will be a RN entry when we remove the experimental tag and the legacy > code. > > > > > > > > > > > > > > > > > > > > > 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 > > required. > > > > > 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)? > > > > > > The original intent of this patch was also to remove the legacy code in > > > 2002 > > 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. > > > > > > > > >
