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
