Re: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: set default

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

Hi Akhil,

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