doc: deprecate legacy code path in ipsec-secgw

  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.iremonger@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
---
 doc/guides/rel_notes/deprecation.rst | 5 +++++
 1 file changed, 5 insertions(+)
  

+Anoob, Jerin

> 
> 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.iremonger@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 37b8592..8efe234 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -78,3 +78,8 @@ Deprecation Notices
>    to set new power environment if power environment was already initialized.
>    In this case the function will return -1 unless the environment is unset first
>    (using ``rte_power_unset_env``). Other function usage scenarios will not
> change.
> +
> +* ipsec-secgw: All the ipsec-secgw legacy code path functionality is now
> +  available in the librte_ipsec library. It is planned to deprecate the legacy
> +  code path in the ipsec-secgw application in the 19.11 release and remove it
> +  in the 20.02 release.
> --
> 2.7.4
  

Hi Anoob,

Could you please Ack this patch if there is no issue?

Thanks,
Akhil

> +Anoob, Jerin
> 
> >
> > 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.iremonger@intel.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 37b8592..8efe234 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -78,3 +78,8 @@ Deprecation Notices
> >    to set new power environment if power environment was already initialized.
> >    In this case the function will return -1 unless the environment is unset first
> >    (using ``rte_power_unset_env``). Other function usage scenarios will not
> > change.
> > +
> > +* ipsec-secgw: All the ipsec-secgw legacy code path functionality is now
> > +  available in the librte_ipsec library. It is planned to deprecate the legacy
> > +  code path in the ipsec-secgw application in the 19.11 release and remove it
> > +  in the 20.02 release.
> > --
> > 2.7.4
  

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Bernard Iremonger
> Sent: Wednesday, July 24, 2019 3:43 PM
> To: dev@dpdk.org; konstantin.ananyev@intel.com; akhil.goyal@nxp.com
> Cc: Bernard Iremonger <bernard.iremonger@intel.com>
> Subject: [EXT] [dpdk-dev] [PATCH] doc: deprecate legacy code path in ipsec-
> secgw
> 
> External Email
> 
> ----------------------------------------------------------------------
> 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.iremonger@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 5 +++++
>  1 file changed, 5 insertions(+)
> 
Acked-by: Anoob Joseph <anoobj@marvell.com>
  

> >
> > ----------------------------------------------------------------------
> > 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.iremonger@intel.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> Acked-by: Anoob Joseph <anoobj@marvell.com>

Applied to dpdk-next-crypto

Thanks.
  

> > > 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.iremonger@intel.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > ---
> > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > >  1 file changed, 5 insertions(+)
> > >
> > Acked-by: Anoob Joseph <anoobj@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.
  

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Monday, July 29, 2019 5:34 PM
> To: Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org; Akhil Goyal <akhil.goyal@nxp.com>; Anoob Joseph <anoobj@marvell.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH] doc: deprecate legacy code path in ipsec-secgw
> 
> > > > 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.iremonger@intel.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > ---
> > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > >  1 file changed, 5 insertions(+)
> > > >
> > > Acked-by: Anoob Joseph <anoobj@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.

Ok, if we don't need a formal deprecation note for that - even better.
Thanks
Konstantin
  

> 
> > > > 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.iremonger@intel.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > ---
> > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > >  1 file changed, 5 insertions(+)
> > > >
> > > Acked-by: Anoob Joseph <anoobj@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. 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.
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.

-Akhil
  

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.iremonger@intel.com>
> > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > ---
> > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > >  1 file changed, 5 insertions(+)
> > > > >
> > > > Acked-by: Anoob Joseph <anoobj@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. 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.
> 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.

The deprecation notice is not the right place for a change in an example.
What change is there in IPsec API? In which release?
  

> 
> 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.iremonger@intel.com>
> > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > ---
> > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > >  1 file changed, 5 insertions(+)
> > > > > >
> > > > > Acked-by: Anoob Joseph <anoobj@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. 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.
> > 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.
> 
> 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.

If deprecation notice is not the right place, then where should it be notified before actually making the
change.
  

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.iremonger@intel.com>
> > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > > ---
> > > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > > >  1 file changed, 5 insertions(+)
> > > > > > >
> > > > > > Acked-by: Anoob Joseph <anoobj@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.
  

> 
> 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.iremonger@intel.com>
> > > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > > > ---
> > > > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > > > >  1 file changed, 5 insertions(+)
> > > > > > > >
> > > > > > > Acked-by: Anoob Joseph <anoobj@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.
  

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.iremonger@intel.com>
> > > > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > > > > ---
> > > > > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > > > > >  1 file changed, 5 insertions(+)
> > > > > > > > >
> > > > > > > > Acked-by: Anoob Joseph <anoobj@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.

That's your take.
When do you plan to remove experimental status of IPsec library?
  

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, July 30, 2019 2:27 PM
> To: Akhil Goyal <akhil.goyal@nxp.com>
> Cc: Bernard Iremonger <bernard.iremonger@intel.com>; dev@dpdk.org; Anoob
> Joseph <anoobj@marvell.com>; konstantin.ananyev@intel.com; Jerin Jacob
> Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>
> Subject: Re: [dpdk-dev] [EXT] [PATCH] doc: deprecate legacy code path in ipsec-
> secgw
> 
> 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.iremonger@intel.com>
> > > > > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > > > > > ---
> > > > > > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > > > > > >  1 file changed, 5 insertions(+)
> > > > > > > > > >
> > > > > > > > > Acked-by: Anoob Joseph <anoobj@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.
> 
> 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.
  

> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Tuesday, July 30, 2019 2:27 PM
> > To: Akhil Goyal <akhil.goyal@nxp.com>
> > Cc: Bernard Iremonger <bernard.iremonger@intel.com>; dev@dpdk.org; Anoob
> > Joseph <anoobj@marvell.com>; konstantin.ananyev@intel.com; Jerin Jacob
> > Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> > <pathreya@marvell.com>
> > Subject: Re: [dpdk-dev] [EXT] [PATCH] doc: deprecate legacy code path in ipsec-
> > secgw
> >
> > 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.iremonger@intel.com>
> > > > > > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > > > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > > > > > > ---
> > > > > > > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > > > > > > >  1 file changed, 5 insertions(+)
> > > > > > > > > > >
> > > > > > > > > > Acked-by: Anoob Joseph <anoobj@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?
Why DPDK sample app can't use DPDK experimental API as it is,
without some alternate code-path?

> >
> > 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)?
Konstantin
  

> > >
> > > 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.iremonger@intel.com>
> > > > > > > > > > > > Acked-by: Konstantin Ananyev
> <konstantin.ananyev@intel.com>
> > > > > > > > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > > > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > > > > > > > >  1 file changed, 5 insertions(+)
> > > > > > > > > > > >
> > > > > > > > > > > Acked-by: Anoob Joseph <anoobj@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. Original Idea for ipsec lib was to have
better performing APIs. How much gain is observed using these APIs on intel?
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. 

> 
> > >
> > > 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.

> Konstantin
  

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.iremonger@intel.com>
> > > > > > > > > > > > > Acked-by: Konstantin Ananyev
> > <konstantin.ananyev@intel.com>
> > > > > > > > > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > > > > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > > > > > > > > >  1 file changed, 5 insertions(+)
> > > > > > > > > > > > >
> > > > > > > > > > > > Acked-by: Anoob Joseph <anoobj@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?

> 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?
Would there be a separate RN when we'll remove experimental tag
and 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.
>
  

Hi Konstantin,
> 
> 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.iremonger@intel.com>
> > > > > > > > > > > > > > Acked-by: Konstantin Ananyev
> > > <konstantin.ananyev@intel.com>
> > > > > > > > > > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > > > > > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > > > > > > > > > >  1 file changed, 5 insertions(+)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > Acked-by: Anoob Joseph <anoobj@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.

> 
> > 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.
> >
> 
> 
>
  

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.iremonger@intel.com>
> > > > > > > > > > > > > > > Acked-by: Konstantin Ananyev
> > > > <konstantin.ananyev@intel.com>
> > > > > > > > > > > > > > > Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> > > > > > > > > > > > > > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > >  doc/guides/rel_notes/deprecation.rst | 5 +++++
> > > > > > > > > > > > > > >  1 file changed, 5 insertions(+)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > Acked-by: Anoob Joseph <anoobj@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.
> > >
> >
> >
> >