RE: [Bug 1107] [22.11-rc1][meson test] seqlock_autotest test failed

["Jiang, YuX" <yux.jiang@intel.com>]

> -----Original Message-----
> From: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> Sent: Tuesday, October 18, 2022 4:44 PM
> To: bugzilla@dpdk.org; dev@dpdk.org
> Cc: David Marchand <david.marchand@redhat.com>; Liang, Cunming
> <cunming.liang@intel.com>
> Subject: Re: [Bug 1107] [22.11-rc1][meson test] seqlock_autotest test failed
> 
> On 2022-10-18 07:57, bugzilla@dpdk.org wrote:
> > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444
> > 5555731-77db8b1c577f1119&q=1&e=8bb9cf17-6273-48ca-96b9-
> 52e8c1287ae2&u=
> > https%3A%2F%2Fbugs.dpdk.org%2Fshow_bug.cgi%3Fid%3D1107
> >
> >              Bug ID: 1107
> >             Summary: [22.11-rc1][meson test] seqlock_autotest test failed
> >             Product: DPDK
> >             Version: 22.11
> >            Hardware: All
> >                  OS: All
> >              Status: UNCONFIRMED
> >            Severity: normal
> >            Priority: Normal
> >           Component: meson
> >            Assignee: dev@dpdk.org
> >            Reporter: yux.jiang@intel.com
> >    Target Milestone: ---
> >
> > [Environment]
> > DPDK version: dpdk22.11.0rc1
> a74b1b25136a592c275afbfa6b70771469750aee
> > OS: CentOS7.9/3.10.0-1160.62.1.el7.x86_64 or
> > 3.10.0-1160.71.1.el7.x86_64
> > Compiler: gcc version 4.8.5 20150623
> 
> Have you tried with a different compiler? Preferably one supported by DPDK,
> unlike 4.8.5.
> 
> Some versions of GCC had problems with C11 release-type thread fences.
> GCC 7.2, for example, could reorder non-atomic stores across the fence.
> (That mightily confused me, when I came across this in my very first program
> using C11-style atomics.)
> 
> It might be worth disassembling the code to make sure that didn't happen in
> your case.
> 
> Also, you could try to replace the release barrier and/or the acquire barrier
> with a rte_compiler_barrier(), just to see if this problem is indeed related to
> the barriers. On a TSO machine, a compiler barrier should do the job. Or you
> use __sync_synchronize(). (Just for exploration, not as a bug fix or workaround.)
> 
Thanks.
Currently it is only found this failure on CentOS7.9.
Can test passed on 22.04.1 LTS (Jammy Jellyfish)/5.15.0-27-generic with GCC gcc version 11.2.0.
So you think this is gcc compiler problem rather than a dpdk bug, right?
And will not fix, right?

> > Hardware platform: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz
> >
> >
> > [Test Setup]
> > Steps to reproduce
> > 1. Use the following command to build DPDK:
> > CC=gcc meson -Denable_kmods=True -Dlibdir=lib --default-library=static
> > x86_64-native-linuxapp-gcc/ ninja -C x86_64-native-linuxapp-gcc/
> >
> > 2. Execute the following command in the dpdk directory.
> > meson test -C x86_64-native-bsdapp-gcc/ seqlock_autotest
> >
> > [Show the output from the previous commands]
> > 2/2 DPDK:fast-tests / seqlock_autotest      FAIL             2.51s   (exit
> > status 255 or signal 127 SIGinvalid)
> > 04:23:38 MALLOC_PERTURB_=139 DPDK_TEST=seqlock_autotest
> > /root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test
> > --file-prefix=seqlock_autotest
> > ----------------------------------- output
> > -----------------------------------
> > stdout:
> > RTE>>seqlock_autotest^M
> > Reader observed inconsistent data values 10856068477537484964
> > 9973142773974991064 9973142773974991064 Test Failed
> > RTE>>
> > stderr:
> > EAL: Detected CPU lcores: 8
> > EAL: Detected NUMA nodes: 1
> > EAL: Detected static linkage of DPDK
> > EAL: Multi-process socket /var/run/dpdk/seqlock_autotest/mp_socket
> > EAL: Selected IOVA mode 'VA'
> > EAL: 1024 hugepages of size 2097152 reserved, but no mounted hugetlbfs
> > found for that size
> > APP: HPET is not enabled, using TSC as default timer
> >
> > [Expected Result]
> > Test ok.
> >