Hello all,

On Fri, 11 Nov 2016 10:34:39 +0000
Hemant Agrawal [off-list ref] 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?

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).

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.

/* 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?

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@broadcom.com]
Sent: Wednesday, September 14, 2016 7:18 PM
To: Hemant Agrawal <redacted>
Cc: Thomas Monjalon <redacted>; users@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@nxp.com<mailto:hemant.agrawal@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

quoted

-----Original Message-----
From: users [mailto:users-bounces@dpdk.org<mailto:users-bounces@dpdk.org>] On Behalf Of Michael Wildt
Sent: Wednesday, September 14, 2016 12:05 AM
To: Thomas Monjalon <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
Cc: users@dpdk.org<mailto:users@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@6wind.com<mailto:thomas.monjalon@6wind.com>  

quoted

wrote:  

quoted

2016-09-13 07:45, Michael Wildt:  

quoted

Hi Thomas,

Appreciate the assistance. Please see inline.


On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <  

thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>  

quoted

wrote:
 

quoted

Hi,

2016-09-12 22:20, Michael Wildt:  

quoted

I'm attempting to cross compile DPDK on an x86 for an ARM64 target.  

This  

quoted

quoted

quoted

fails in the following areas, using latest dpdk as of 9/12. When  

compiling  

quoted

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-  

quoted

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-  

quoted

ARCH=arm64 RTE_KERNELDIR=/projects/kernel
 

quoted

quoted

- librte_vhost, fails with:

/projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-  

net-user.c:250:23:  

quoted

error: array subscript is above array bounds [-Werror=array-bounds]
   rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];  

[...]  

quoted

- 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:  

quoted

quoted

quoted

Error: no such instruction: `rev16 %bx,%bx'  

[...]  

quoted

  - 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@RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic