Hi Cristian, > -----Original Message----- > From: Dumitrescu, Cristian <cristian.dumitre...@intel.com> > Sent: Wednesday, April 21, 2021 4:58 PM > To: Ali Alnubani <alia...@nvidia.com>; NBU-Contact-Thomas Monjalon > <tho...@monjalon.net>; Aaron Conole <acon...@redhat.com> > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 2/2] pipeline: autodetect endianness of > action args > > > > > -----Original Message----- > > From: Ali Alnubani <alia...@nvidia.com> > > Sent: Wednesday, April 21, 2021 8:50 AM > > To: NBU-Contact-Thomas Monjalon <tho...@monjalon.net>; Dumitrescu, > > Cristian <cristian.dumitre...@intel.com>; Aaron Conole > > <acon...@redhat.com> > > Cc: dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH 2/2] pipeline: autodetect endianness of > > action args > > > > Hi, > > > > > -----Original Message----- > > > From: dev <dev-boun...@dpdk.org> On Behalf Of Thomas Monjalon > > > Sent: Tuesday, April 20, 2021 10:58 PM > > > To: Cristian Dumitrescu <cristian.dumitre...@intel.com> > > > Cc: dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 2/2] pipeline: autodetect endianness of > > > action args > > > > > > 12/04/2021 01:23, Cristian Dumitrescu: > > > > Each table entry is made up of match fields and action data, with the > > > > latter made up of the action ID and the action arguments. The approach > > > > of having the user specify explicitly the endianness of the action > > > > arguments is difficult to be picked up by P4 compilers, as the P4 > > > > compiler is generally unaware about this aspect. > > > > > > > > This commit introduces the auto-detection of the endianness of the > > > > action arguments by examining the endianness of the their destination: > > > > network byte order (NBO) when they get copied to headers and host > > byte > > > > order (HBO) when they get copied to packet meta-data or mailboxes. > > > > > > > > The endianness specification of each action argument as part of the > > > > rule specification, e.g. H(...) and N(...) is removed from the rule > > > > file and auto-detected based on their destination. The DMA instruction > > > > scope is made internal, so mov instructions need to be used. The > > > > pattern of transferring complete headers from table entry action args > > > > to headers is detected, and the associated set of mov instructions > > > > plus header validate is internally detected and replaced with the > > > > internal-only DMA instruction to preserve performance. > > > > > > > > Signed-off-by: Cristian Dumitrescu <cristian.dumitre...@intel.com> > > > > > > Series applied, thanks > > > > > > > > > > I believe this patchset is causing the build failures in > > https://bugs.dpdk.org/show_bug.cgi?id=683. > > > > Regards, > > Ali > > Hi Ali, > > I checked this issue and here are my findings: > > 1. The compiler warnings are NOT caused by this patch, all of them are > triggered by older code.
Git-bisect pointed to this patch. The errors didn't reproduce without it. > 2. Why were they not triggered before? Either this is the first time CentOS 7 > is run or the compiler has a mind of its own (my vote goes to the former). The check ci/iol-testing contains an image with gcc 4.8.5 (RHEL 7), and I see now that it reproduced the errors in recent patches. See the failing build check in https://lab.dpdk.org/results/dashboard/patchsets/16682/ (under dpdk_meson_compile). > 3. These are all 100% fake issues that are probably triggered by the old GCC > version from CentOS 7. > > I just sent a patch now (you are copied on it) with some harmless local > variable initializations in the hope it will stop these warnings on CentOS 7. > As I > don't have access to a CentOS 7 machine, can you please confirm whether > the warnings are fixed? > I submitted a patch and updated the status of the Bugzilla ticket a few hours ago. See https://bugs.dpdk.org/show_bug.cgi?id=683#c4. > As the warnings are triggered selectively for just more occurrences of a > common pattern as opposed to all occurrences, I am trying to fix all > occurrences of this pattern in order to prevent the same warnings showing > up again. > I only initialized occurrences of dst_struct_id and src_struct_id to resolve it though, maybe rebase and update your patch if you think initializing the rest is necessary? Thanks, Ali
