DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
Subject: Re: [dpdk-dev] [PATCH] ethdev: fix dpdk gcc build on Arm
Date: Thu, 4 Jun 2020 14:41:31 +0100	[thread overview]
Message-ID: <20200604134131.GA1543@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <235a60eb9b164c3e8b62ef531db784b5@pantheon.tech>

On Thu, Jun 04, 2020 at 12:55:40PM +0000, Juraj Linkeš wrote:
> > -----Original Message-----
> > From: Ferruh Yigit <ferruh.yigit@intel.com>
> > Sent: Thursday, June 4, 2020 2:23 PM
> > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Thomas Monjalon
> > <thomas@monjalon.net>
> > Cc: arybchenko@solarflare.com; dev@dpdk.org; Honnappa Nagarahalli
> > <Honnappa.Nagarahalli@arm.com>
> > Subject: Re: [PATCH] ethdev: fix dpdk gcc build on Arm
> > 
> > On 6/4/2020 11:36 AM, Juraj Linkeš wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Ferruh Yigit <ferruh.yigit@intel.com>
> > >> Sent: Wednesday, June 3, 2020 1:41 PM
> > >> To: Thomas Monjalon <thomas@monjalon.net>; Juraj Linkeš
> > >> <juraj.linkes@pantheon.tech>
> > >> Cc: arybchenko@solarflare.com; dev@dpdk.org
> > >> Subject: Re: [PATCH] ethdev: fix dpdk gcc build on Arm
> > >>
> > >> On 6/3/2020 11:16 AM, Thomas Monjalon wrote:
> > >>> 03/06/2020 11:48, Juraj Linkeš:
> > >>>> Directive #include <file> in gcc implementation searches for files
> > >>>> in a standard list of system directories, which leads to a
> > >>>> sporadici build error on Taishan arm machines:
> > >>>> /tmp/openvpp-testing/dpdk/lib/librte_ethdev/rte_ethdev.h:4287:10:
> > >>>> fatal error: rte_ethdev_core.h:
> > >>>> No such file or directory #include <rte_ethdev_core.h>
> > >>>
> > >>> Would be interesting to know why nobody else hit such error?
> > >>
> > >>
> > >> I can't see why this is happening, in the 'mk/rte.lib.mk' we have following:
> > >>
> > >> "
> > >> install: _preinstall build _postinstall
> > >> build: _preinstall
> > >> "
> > >>
> > >> Which should cause the library header files installed before building
> > >> .c files in that library.
> > >> So when compiling 'rte_class_eth.c', the header files should be
> > >> already in install folder.
> > >>
> > >>
> > >> I can see how/why changing to "" fixes the issue but I am not sure about this
> > fix.
> > >> "rte_ethdev.h" is a public header file, that applications will
> > >> include it in their applications. In the public library it is more
> > >> proper to have other includes from system folder, using format <>.
> > >> Again, I can't see why it is failing but I believe we should find
> > >> another solution for _internal_ build error.
> > >>
> > >>
> > >> A very simple solution can be following, but that is also not good,
> > >> since it solves the issue by creating a dependency to the order of the header
> > includes:
> > >>  diff --git a/lib/librte_ethdev/rte_class_eth.c
> > >> b/lib/librte_ethdev/rte_class_eth.c
> > >>  index 6338355e25..3030c49020 100644
> > >>  --- a/lib/librte_ethdev/rte_class_eth.c
> > >>  +++ b/lib/librte_ethdev/rte_class_eth.c
> > >>  @@ -10,8 +10,8 @@
> > >>   #include <rte_kvargs.h>
> > >>   #include <rte_log.h>
> > >>
> > >>  -#include "rte_ethdev.h"
> > >>   #include "rte_ethdev_core.h"
> > >>  +#include "rte_ethdev.h"
> > >>   #include "rte_ethdev_driver.h"
> > >>   #include "ethdev_private.h"
> > >>
> > >
> > > Thomas, Ferruh, what should be the solution? I'm not an expert on this and I
> > can't really offer anything better, but I'd like that this gets fixed.
> > 
> > First we need to root cause this before trying to solve it. Honnappa also said he
> > can reproduce this but our CI builds can't (we are talking about tens of builds
> > daily on various platforms), need to understand why.
> > Also from Makefile I can't see how this is happening, I am feeling uneasy to fix
> > something before figuring out how/why it is failing.
> > 
> > Can you please try to collect more data on when/how this happens, initial
> > questions I can think of:
> > - Can you reproduce this with meson build?
> > - Is it bare DPDK build, or build part of other project (I guess I saw fd.io on the
> > link)
> > - - If this is not bare DPDK build what changes has been done to build system?
> > - Do you see this with fresh build (new clone) or rebuild of existing clone?
> > - Can you confirm you have correct RTE_SDK and RTE_TARGET environment
> > variables?
> > - Can you please share your build command?
> > 
> 
> I sent an e-mail to dpdk dev a few days back asking for help where I outlined what we're doing:
> We're not doing anything special, just downloading and extracting the archive, then setting CONFIG_RTE_LIBRTE_MLX5_PMD and CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC to y in config/common_base and then running make install T=arm64-armv8a-linuxapp-gcc -j. As mentioned in the subject, the build server is a Taishan ARM server.
> 
> We're doing a fresh rebuild everytime. The error doesn't happen everytime, just sometimes - it seems to be random.
> 
> We don't set RTE_SDK nor RTE_TARGET since https://doc.dpdk.org/guides/linux_gsg/build_dpdk.html#installation-of-dpdk-target-environment-using-make doesn't mention those.
> 
> I'll try Meson build a few times. How can I enable those two config options in Meson?
> 

The MLX drivers will be enabled automatically if the required dependencies
are found. There is no meson build option to switch to using 16B
descriptors in the i40e driver, since we are really trying to limit the
build-time configurability in meson. However, you should be able to enable
it by setting "-DRTE_LIBRTE_I40E_16BYTE_RX_DESC" in CFLAGS before calling
meson.

  parent reply	other threads:[~2020-06-04 13:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03  9:48 Juraj Linkeš
2020-06-03 10:16 ` Thomas Monjalon
2020-06-03 10:23   ` Ananyev, Konstantin
2020-06-03 10:47   ` Juraj Linkeš
2020-06-03 12:05     ` Thomas Monjalon
2020-06-03 11:40   ` Ferruh Yigit
2020-06-04 10:36     ` Juraj Linkeš
2020-06-04 12:22       ` Ferruh Yigit
2020-06-04 12:50         ` Ferruh Yigit
2020-06-04 12:55         ` Juraj Linkeš
2020-06-04 13:29           ` Ferruh Yigit
2020-06-05 11:59             ` Juraj Linkeš
2020-06-08  8:17             ` Juraj Linkeš
2020-06-08 11:38               ` Ferruh Yigit
2020-06-08 12:03                 ` Juraj Linkeš
2020-06-08 12:39                   ` Ferruh Yigit
2020-06-08 13:19                     ` Juraj Linkeš
2020-06-08 13:46                       ` Ferruh Yigit
2020-06-04 13:41           ` Bruce Richardson [this message]
2020-06-05 12:00             ` Juraj Linkeš
2020-06-05 12:55               ` Bruce Richardson
2020-06-03 13:58   ` Honnappa Nagarahalli

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=20200604134131.GA1543@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=juraj.linkes@pantheon.tech \
    --cc=thomas@monjalon.net \
    /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).