-----Original Message----- > Date: Mon, 11 Jun 2018 04:05:26 +0000 > From: Sachin Saxena <sachin.sax...@nxp.com> > To: Jerin Jacob <jerin.ja...@caviumnetworks.com>, Hemant Agrawal > <hemant.agra...@nxp.com> > CC: "dev@dpdk.org" <dev@dpdk.org> > Subject: RE: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA > machine > > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > > Sent: Sunday, June 10, 2018 4:37 PM > > To: Hemant Agrawal <hemant.agra...@nxp.com> > > Cc: dev@dpdk.org; Sachin Saxena <sachin.sax...@nxp.com> > > Subject: Re: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA > > machine > > > > -----Original Message----- > > > Date: Tue, 5 Jun 2018 12:03:45 +0530 > > > From: Hemant Agrawal <hemant.agra...@nxp.com> > > > To: dev@dpdk.org > > > CC: Sachin Saxena <sachin.sax...@nxp.com> > > > Subject: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA > > > machine > > > X-Mailer: git-send-email 2.7.4 > > > > > > From: Sachin Saxena <sachin.sax...@nxp.com> > > > > > > Random corruptions observed on ARM platfoms with using the dpdk > > > library in shared mode with VPP software (plugin). > > > > > > sing traditional TLS scheme resolved the issue. > > > > > > Tested with VPP with DPDK as a plugin. > > > > > > Signed-off-by: Sachin Saxena <sachin.sax...@nxp.com> > > > --- > > > mk/machine/armv8a/rte.vars.mk | 3 +++ > > > mk/machine/dpaa/rte.vars.mk | 3 +++ > > > mk/machine/dpaa2/rte.vars.mk | 3 +++ > > > 3 files changed, 9 insertions(+) > > > > > > diff --git a/mk/machine/armv8a/rte.vars.mk > > > b/mk/machine/armv8a/rte.vars.mk index 8252efb..6897cd6 100644 > > > --- a/mk/machine/armv8a/rte.vars.mk > > > +++ b/mk/machine/armv8a/rte.vars.mk > > > @@ -29,3 +29,6 @@ > > > # CPU_ASFLAGS = > > > > > > MACHINE_CFLAGS += -march=armv8-a+crc+crypto > > > + > > > +# To avoid TLS corruption issue. > > > +MACHINE_CFLAGS += -mtls-dialect=trad > > > > This issue is not reproducible on Cavium ARMv8 platforms. Just wondering, > > Do we need to change default ARMv8 config? > [Sachin Saxena] The issue is currently visible On NXP platforms with > VPP-dpdk solution only. Similar behavior like random crashes or > initialization failures have been seen by Cavium guys on VPP but they are > still investigating whether the issues are related to TLS corruption.
I checked with Cavium-VPP team. According to them, they are not facing any issue related to TLS > Also, issue will not be there with statically linked dpdk applications > > > > > The GNU (descriptor) dialect for TLS is the default has been since for a > > while > > on aarch64. > [Sachin Saxena] I agree but this model only applies to Shared mode > compilation. As per my knowledge, the "initial-exec" model is default for > static compilation or when -fPIC is not used. For shared dpdk or when -fPIC > is used, the default is "global-dynamics" and tls-dialect=desc. But shared mode compilation is important too. Right? We are concerned about performance and stability aspects of "changing default" with out any proper root cause. > > > > > I think, it will be mostly a glibc issue with your SDK based toolchain. > > Are you able to reproduce this issue with Linaro toolchain + standard OS > > distribution environments? if so, could you please share more details. > [Sachin Saxena] Yes, issue is happening with both SDK & Linaro 7.2 toolchain. We tested and it works with gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9). If it is bug from Linaro on the latest toolchain, lets report and try to have this fix based on runtime attributes. > > > > I am only concerned about, any performance issue with traditional tls > > dialect > > model vs descriptor dialect. > [Sachin Saxena] No performance impact is expected for statically build dpdk. > For shared mode, minor impact is expected but performance analysis is yet to > be done. The Fix is suggested because right now it is functionally broken > with VPP. Is it possible to check with "gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9)"? so that we can identity it is an toolchain issue or not? > > > > I think, we have two options, > > 1) If you can identify if it is due a specific glibc version then we could > > detect > > at runtime > > 2) In a worst case, it can be a conditional compilation option. > > > > /Jerin >
