[dpdk-dev] [PATCH v5 3/6] net/axgbe: use common rte bitoperation APIs instead

Thomas Monjalon thomas at monjalon.net
Mon Dec 2 10:30:09 CET 2019


02/12/2019 10:24, Morten Brørup:
> Thomas,
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Monday, December 2, 2019 10:12 AM
> > 
> > 02/12/2019 07:09, Gavin Hu (Arm Technology China):
> > > Hi Bruce, Thomas,
> > >
> > > This series of patches was reported a compilation issue[1] on 32bit
> > Ubuntu.
> > > On mainstream 64-bit OS,  "unsigned long" is 64-bit in size and we
> > uses the 64-bit variant of APIs. But the 32-bit OS expect 32-bit
> > 'unsigned long' arguments.
> > > This is where the error happens.
> > 
> > Please could you be more specific? What is the exact error?
> 
> The PMD has a private structure with an unsigned long field.
> 
> The patch for the PMD uses the 64 bit operations on this field. The patch fails to compile for a 32 bit target, because the struct field is only 32 bit there.
> 
> > 
> > > My question is how 32-bit OSes shall we support, put another way, can
> > we ignore this compilation issue?
> > > If we still need to care, how about making 'obsolete' of 'unsigned
> > long' and use 'uint32' instead to be multi-OS friendly?
> > 
> > Which unsigned long?
> > If it is in the (not merged) bit API, it can still be changed no?
> > 
> 
> The patch for the PMD can be changed to use the 64 or 32 bit operations depending on whether it is being compiled for a 64 or 32 bit target.
> 
> However, the question seems to be if we want to either 1) do something like that, or 2) drop support for 32 bit targets, or 3) make these target dependent fields obsolete (i.e. ban the use of unsigned long) and require explicit sizes, e.g. uint32_t.

We should support both,
and use the appropriate instruction.

But I wonder why this field has not a fixed size.
It would be probably better to change the field to uint32_t or uint64_t.




More information about the dev mailing list