[dpdk-users] pmdinfogen issues: cross compilation for ARM fails with older host compiler

Neil Horman nhorman at tuxdriver.com
Fri Nov 11 20:25:06 CET 2016
Previous message: [dpdk-users] pmdinfogen issues: cross compilation for ARM fails with older host compiler
Next message: [dpdk-users] pmdinfogen issues: cross compilation for ARM fails with older host compiler
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Nov 11, 2016 at 02:48:51PM +0100, Jan Viktorin wrote:
> Hello all,
> 
> On Fri, 11 Nov 2016 10:34:39 +0000
> Hemant Agrawal <hemant.agrawal at nxp.com> wrote:
> 
> > Hi Neil,
> >                Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
> 
> This seems wierd to me... why is it so? I couldn't find any usage of rte_byteorder.h in the source of pmdinfogen
> (what am I missing?). Why is it included there?
> 
See the CONVERT_NATIVE macro in pmdinfogen.h.  It makes use of the various
rte_[le|be]_to_cpu macros from rte_byteorder.h

> The pmdinfogen executes on the host but works with the (cross-compiled) target binaries. Is that right? If the tool
> needs to know endianity then we probably need a header telling just the target's endianity (or other metadata).
> 
pmdinfogen works on ELF object files, and can extract the endianess from the ELF
header itself (using the e_ident[EI_DATA] area).

> > However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
> > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.
> 
> This is not the actual issue. Consider an ARM build server that cross-compiles DPDK for Intel x86 (I admit that this
> is quite a ridiculous situation, so take it easy ;)). Then we have just opposite issues... Would we like to fill the
> DPDK x86 code base with #ifdef...#endif everytime there is some assembly code? I'd just like to point out that this
> single instruction is not the true source of the problem. It is like complaining that nasm cannot compile Thumb2
> instructions... No it cannot, sorry.
> 
It sounds like the issue is a general 'how to get support for another arch'
question.  In the case of rte_byteorder.h, its actually pretty cut and dry,
because thankfully all the instructions are wrapped up into nice C inline
functions or macros.  The trick is to simply define the api instructions in the
file for each arch, with a default generic case that just uses C, so it can be
compiled into whatever the target arch needs (although it may run more slowly).
That gets you initial support, and then you can optimize be creating a special
case for the new arch.  You have to do that for every API set that has per-arch
optimizations (the atomic ops, the tsc ops, memcpy, cpuflags, prefetch, etc).
Its time consuming, but its just the way it is.

> > 
> > /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> > #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >                register uint16_t x = _x;
> >                asm volatile ("rev16 %0,%1"
> >                                     : "=r" (x)
> >                                     : "r" (x)
> >                                     );
> >                return x;
> > }
> > #endif
> > 
> > One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
> > e.g
> > #if !(defined __arm__ || defined __aarch64__)
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >                return (_x >> 8) | ((_x << 8) & 0xff00);
> > }
> > #else ….
> > 
> > Is there a better way to fix it?
> 
Well, almost, what you have above is a good solution, but it shouldn't be the
ARM solution, it should be the code used if an arch specific variant of the code
isn't defined. The pattern rte_byteorder should follow is

#if (defined i686 || defined x86_64)
	<x86 specific implementation of rte_arch_bswap16>
#elif (defined ppc || ppc64)
	<ppc specific implementation of rte_arch_bswap16>
#else
	<generic implementation of rte_arch_bswap16>
#endif

The idea is to have a generic version that works for any arch to fall back on,
then if you have a faster way to do it on your arch, you can add a clause at
your leisure to do so.

Neil

> In my opinion, this would work as a hotfix but not as a solution.
> 
> Kind regards
> Jan
> 
> > 
> > Regards,
> > Hemant
> > 
> > 
> > From: Michael Wildt [mailto:michael.wildt at broadcom.com]
> > Sent: Wednesday, September 14, 2016 7:18 PM
> > To: Hemant Agrawal <hemant.agrawal at nxp.com>
> > Cc: Thomas Monjalon <thomas.monjalon at 6wind.com>; users at dpdk.org
> > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and pmdinfogen issues
> > 
> > Hi Hemant,
> > 
> > Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 but good to know.
> > 
> > I gave that one a try and that works as well but as with the 5.3 I have to be on a Ubuntu not RHEL6 to make it work.
> > 
> > Thanks,
> > Michael
> > 
> > On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal <hemant.agrawal at nxp.com<mailto:hemant.agrawal at nxp.com>> wrote:
> > Hi Michael,
> >         One of the problem, I found with Linaro gcc 4.9 toolchain for i686 (default one), that it seems to be built with older kernel headers (<3.8). This usages older linux/vhost.h file.
> > 
> > However, we have not observed this issue with x86_64 based toolchain on 64 bit m/c.
> >  https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
> > 
> > Regards,
> > Hemant
> > 
> > > -----Original Message-----
> > > From: users [mailto:users-bounces at dpdk.org<mailto:users-bounces at dpdk.org>] On Behalf Of Michael Wildt
> > > Sent: Wednesday, September 14, 2016 12:05 AM
> > > To: Thomas Monjalon <thomas.monjalon at 6wind.com<mailto:thomas.monjalon at 6wind.com>>
> > > Cc: users at dpdk.org<mailto:users at dpdk.org>
> > > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and
> > > pmdinfogen issues
> > >
> > > Hi Thomas,
> > >
> > > The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a test
> > > application. Its actually 4.9.2.
> > >
> > > Tried a newer Linaro tool chain, turned out to be a bit more complicated since
> > > that does not work on RHEL6, is however a success. With Linaro 5.3 one can
> > > cross compile dpdk fine with no errors, though the rte_byteorder.h file still
> > > points to arm's version, but pmdinfogen builds.
> > >
> > > Probably should still fix both issues just to keep the base clean.
> > >
> > > At least I have a workaround in the interim.
> > >
> > > Thanks for the help.
> > >
> > > Thanks,
> > > Michael
> > >
> > >
> > > On Tue, Sep 13, 2016 at 11:07 AM, Thomas Monjalon
> > > <thomas.monjalon at 6wind.com<mailto:thomas.monjalon at 6wind.com>  
> > > > wrote:  
> > >  
> > > > 2016-09-13 07:45, Michael Wildt:  
> > > > > Hi Thomas,
> > > > >
> > > > > Appreciate the assistance. Please see inline.
> > > > >
> > > > >
> > > > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <  
> > > > thomas.monjalon at 6wind.com<mailto:thomas.monjalon at 6wind.com>>  
> > > > > wrote:
> > > > >  
> > > > > > Hi,
> > > > > >
> > > > > > 2016-09-12 22:20, Michael Wildt:  
> > > > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 target.  
> > > > This  
> > > > > > > fails in the following areas, using latest dpdk as of 9/12. When  
> > > > > > compiling  
> > > > > > > natively there are no issues.  
> > > > > >
> > > > > > Your analysis below seems good.
> > > > > > Interestingly, I do not see such error (don't know why).
> > > > > > Please could you share the commands you are using?
> > > > > >  
> > > > >
> > > > > Sure can.
> > > > >
> > > > > make config T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/  
> > > > bin/aarch64-linux-gnu-  
> > > > > ARCH=arm64
> > > > >
> > > > > make T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/  
> > > > bin/aarch64-linux-gnu-  
> > > > > ARCH=arm64 RTE_KERNELDIR=/projects/kernel
> > > > >  
> > > > > > > - librte_vhost, fails with:
> > > > > > >
> > > > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-  
> > > > > > net-user.c:250:23:  
> > > > > > > error: array subscript is above array bounds [-Werror=array-bounds]
> > > > > > >    rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];  
> > > > > > [...]  
> > > > > > > - buildtools/pmdinfogen, fails with:
> > > > > > >
> > > > > > > == Build buildtools/pmdinfogen
> > > > > > >   HOSTCC pmdinfogen.o
> > > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_byteorder.h:
> > > > > > > Assembler messages:
> > > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_  
> > > > byteorder.h:53:  
> > > > > > > Error: no such instruction: `rev16 %bx,%bx'  
> > > > > > [...]  
> > > > > > >   - The issue is due to the rte_byteorder.h file which gets
> > > > > > >   symlink'ed with the ARM version at the beginning of the build.
> > > > > > >   The pmdinfogen is always compiled for x86 thus the asm is failing.  
> > > >
> > > > It is definitely something to fix.
> > > > In the meantime, you should be able to compile DPDK by using a more
> > > > recent toolchain. This error is in:
> > > >
> > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > > >
> > > > I know you are using gcc-4.9 but maybe __GNUC_MINOR__ is wrong in yours.
> > > >
> > > >  
> > 
> 
> 
> 
> -- 
>    Jan Viktorin                  E-mail: Viktorin at RehiveTech.com
>    System Architect              Web:    www.RehiveTech.com
>    RehiveTech
>    Brno, Czech Republic
>
Previous message: [dpdk-users] pmdinfogen issues: cross compilation for ARM fails with older host compiler
Next message: [dpdk-users] pmdinfogen issues: cross compilation for ARM fails with older host compiler
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the users mailing list