Hi Konstantin,
> > 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. > IMO, Option 1 is the only way forward. From NXP side, we can start our work on this post 19.11 release and should target in 20.02 release. Regards, Akhil
