DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jan Viktorin <viktorin@rehivetech.com>
To: Hemant Agrawal <hemant.agrawal@nxp.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	"dev@dpdk.org" <dev@dpdk.org>, "users@dpdk.org" <users@dpdk.org>,
	"Jacob,  Jerin" <Jerin.Jacob@cavium.com>
Subject: Re: [dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler
Date: Fri, 11 Nov 2016 14:48:51 +0100	[thread overview]
Message-ID: <20161111144851.3154a651@pcviktorin.fit.vutbr.cz> (raw)
In-Reply-To: <DB5PR04MB1605F64CF0D986E0B2B26AF089BB0@DB5PR04MB1605.eurprd04.prod.outlook.com>

Hello all,

On Fri, 11 Nov 2016 10:34:39 +0000
Hemant Agrawal <hemant.agrawal@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?

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 <hemant.agrawal@nxp.com>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; 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
> 
> > -----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>  
> > > 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@6wind.com<mailto:thomas.monjalon@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@RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

  reply	other threads:[~2016-11-11 13:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-11 10:34 Hemant Agrawal
2016-11-11 13:48 ` Jan Viktorin [this message]
2016-11-11 19:25   ` Neil Horman
2016-11-13 20:59 ` Jerin Jacob
2016-11-14 14:48   ` Neil Horman
2016-11-15  9:34     ` Hemant Agrawal
2016-11-15 14:27       ` Neil Horman
2016-11-15 16:33         ` Thomas Monjalon
2016-11-15 15:08       ` Neil Horman
2016-11-18 12:03         ` Hemant Agrawal
2016-11-18 13:50           ` Neil Horman
2016-11-18 16:37             ` Bruce Richardson
2016-11-18 18:39               ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161111144851.3154a651@pcviktorin.fit.vutbr.cz \
    --to=viktorin@rehivetech.com \
    --cc=Jerin.Jacob@cavium.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=nhorman@tuxdriver.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).