[dpdk-dev] [PATCH 2/2] pipeline: autodetect endianness of action args

[Ali Alnubani]

Hi Cristian,

> -----Original Message-----
> From: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>
> Sent: Wednesday, April 21, 2021 4:58 PM
> To: Ali Alnubani <alialnu at nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas at monjalon.net>; Aaron Conole <aconole at redhat.com>
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 2/2] pipeline: autodetect endianness of
> action args
> 
> 
> 
> > -----Original Message-----
> > From: Ali Alnubani <alialnu at nvidia.com>
> > Sent: Wednesday, April 21, 2021 8:50 AM
> > To: NBU-Contact-Thomas Monjalon <thomas at monjalon.net>; Dumitrescu,
> > Cristian <cristian.dumitrescu at intel.com>; Aaron Conole
> > <aconole at redhat.com>
> > Cc: dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 2/2] pipeline: autodetect endianness of
> > action args
> >
> > Hi,
> >
> > > -----Original Message-----
> > > From: dev <dev-bounces at dpdk.org> On Behalf Of Thomas Monjalon
> > > Sent: Tuesday, April 20, 2021 10:58 PM
> > > To: Cristian Dumitrescu <cristian.dumitrescu at intel.com>
> > > Cc: dev at 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.dumitrescu at 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