[dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA machine

Sachin Saxena sachin.saxena at nxp.com
Mon Jun 11 06:05:26 CEST 2018


> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Sunday, June 10, 2018 4:37 PM
> To: Hemant Agrawal <hemant.agrawal at nxp.com>
> Cc: dev at dpdk.org; Sachin Saxena <sachin.saxena at 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.agrawal at nxp.com>
> > To: dev at dpdk.org
> > CC: Sachin Saxena <sachin.saxena at 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.saxena at 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.saxena at 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.
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.

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



More information about the dev mailing list