From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E463243411; Thu, 30 Nov 2023 14:48:45 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 77B5E42E8B; Thu, 30 Nov 2023 14:48:45 +0100 (CET) Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by mails.dpdk.org (Postfix) with ESMTP id B03FB402F0 for ; Thu, 30 Nov 2023 14:48:44 +0100 (CET) Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 2D9BD40331 for ; Thu, 30 Nov 2023 13:48:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1701352124; bh=aq+fDhzAqKo6bY3E5LrCGxYuas+AS7KZPfrIMFQ9iUY=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=un1nGzZItgHTEcs91kH2fWHdwIBlXSa9v5wqaHWKn9LCpnR81inz3xSlxHE5FSYGD 0arVHYfsaFIIbqDVJsyK3GkNcFHNxpYNynJyM7PFJ4qxb8C7m1Up4MNIikKPqYcrkq DMnyqAzt8ewU0Klh8RJETJsH9kcIx12lwkDKtY0x4Y894OXVOoO5B18xGNBKpzF+qY E3PfN17E31yY7v8vhDEsQU7YNXPBk8NTjFmnDl9VCXGiQZbm5Aq+SBXbctJxLiyzVM mnNmJEHHqyGuz4QB3cieeKMzFzPR+3ydg68/mfLrPXYtuvPphHL0U8oHTulZKThVvJ Y7gtd6li8IXJw== Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-2864530dbf1so371136a91.0 for ; Thu, 30 Nov 2023 05:48:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701352122; x=1701956922; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aq+fDhzAqKo6bY3E5LrCGxYuas+AS7KZPfrIMFQ9iUY=; b=F7P8h8lI3HSz8aZRCYKkFbbEvI5qsxyeSQdto2xLrOtkJ0bGN3SuVOBrFRHMcnibqp ert2L8Eo7L5tWsR7J/UcE/z7DOkBdM0gjS8wJnjpYCFu2GZyfFAQbwJmnJ/R/Ed7LiWy GKTW1vcM0csne1BwzAQZXXfxDUrJ94/GIntz0IV6iaA+hMiMjk1D7IrillAUB+CS30GR p7Sy4GXtlZJ2uztUxp1J1MkyIkfqbGmaZNBGgBwtzCOvu10bGr/r0ttPh8GWt2xtPczS zzyt7/7yixjUEeUo+Vap90ds1JnpChL1DtGJmtbrYOEAAUMTnNYXrkaMsTCa1Pwidveu /WJA== X-Gm-Message-State: AOJu0YzlRyb4lYIhJTWjEnLecrJdKda6nOV+Zua3EeU9rctuFPJWNv83 IflSh7ZXcqWub+s1ivO8OuB9QAO9kbCgJLA5Ferlp/EjDNOZiT5dkhHQeqwQknDSBoy6z6bnwHc NFn6xgYMp7zQooGssBW2Z8J7CosqwPH9f/WHHuA9EnzEsa9c= X-Received: by 2002:a17:90a:d982:b0:285:3444:94e7 with SMTP id d2-20020a17090ad98200b00285344494e7mr22099945pjv.28.1701352122582; Thu, 30 Nov 2023 05:48:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IFcUD+57vYk1HkDjSwDL/ebFcGgSrUrOtLWt2TDNuxUwxh2GPm3nllFUFkiu7cUXaNAzfJbjj4rXQ7BP1DRzxA= X-Received: by 2002:a17:90a:d982:b0:285:3444:94e7 with SMTP id d2-20020a17090ad98200b00285344494e7mr22099919pjv.28.1701352122115; Thu, 30 Nov 2023 05:48:42 -0800 (PST) MIME-Version: 1.0 References: <20231124100904.388453-1-christian.ehrhardt@canonical.com> In-Reply-To: From: Christian Ehrhardt Date: Thu, 30 Nov 2023 14:48:15 +0100 Message-ID: Subject: Re: [PATCH v2] eal/linux: force iova-mode va without pa available To: David Christensen , Luca Boccassi Cc: dev@dpdk.org Content-Type: multipart/alternative; boundary="000000000000e094c2060b5ee8c3" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000e094c2060b5ee8c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 29, 2023 at 10:51=E2=80=AFPM David Christensen wrote: > > > On 11/24/23 2:09 AM, christian.ehrhardt@canonical.com wrote: > > From: David Wilder > > > > When using --no-huge option physical address are not guaranteed > > to be persistent. > > > > This change effectively makes "--no-huge" the same as > > "--no-huge --iova-mode=3Dva". > > > > When --no-huge is used (or any other condition making physical > > addresses unavailable) setting --iova-mode=3Dpa will have no effect. > > > > Signed-off-by: Christian Ehrhardt > > --- > > doc/guides/prog_guide/env_abstraction_layer.rst | 9 ++++++--- > > lib/eal/linux/eal.c | 16 ++++++++++------ > > 2 files changed, 16 insertions(+), 9 deletions(-) > > > > diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst > b/doc/guides/prog_guide/env_abstraction_layer.rst > > index 6debf54efb..20c7355e0f 100644 > > --- a/doc/guides/prog_guide/env_abstraction_layer.rst > > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst > > @@ -559,9 +559,12 @@ IOVA Mode is selected by considering what the > current usable Devices on the > > system require and/or support. > > > > On FreeBSD, RTE_IOVA_PA is always the default. On Linux, the IOVA mod= e > is > > -detected based on a 2-step heuristic detailed below. > > +detected based on a heuristic detailed below. > > > > -For the first step, EAL asks each bus its requirement in terms of IOVA > mode > > +For the first step, if no Physical Addresses are available RTE_IOVA_VA > is > > +selected. > > + > > +Then EAL asks each bus its requirement in terms of IOVA mode > > and decides on a preferred IOVA mode. > > > > - if all buses report RTE_IOVA_PA, then the preferred IOVA mode is > RTE_IOVA_PA, > > @@ -575,7 +578,7 @@ and decides on a preferred IOVA mode. > > If the buses have expressed no preference on which IOVA mode to pick, > then a > > default is selected using the following logic: > > > > -- if physical addresses are not available, RTE_IOVA_VA mode is used > > +- if enable_iova_as_pa was not set at build RTE_IOVA_VA mode is used > > - if /sys/kernel/iommu_groups is not empty, RTE_IOVA_VA mode is used > > - otherwise, RTE_IOVA_PA mode is used > > > > diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c > > index 57da058cec..2f1fce3c54 100644 > > --- a/lib/eal/linux/eal.c > > +++ b/lib/eal/linux/eal.c > > @@ -1067,6 +1067,16 @@ rte_eal_init(int argc, char **argv) > > > > phys_addrs =3D rte_eal_using_phys_addrs() !=3D 0; > > > > + if (!phys_addrs) { > > + /* if we have no access to physical addresses, pick IOVA > as VA mode. */ > > + if (internal_conf->iova_mode =3D=3D RTE_IOVA_PA) > > + RTE_LOG(WARNING, EAL, "WARNING: --iova-mode=3Dpa, > but Physical addresses are unavailable, selecting IOVA as VA mode.\n"); > > + else > > + RTE_LOG(DEBUG, EAL, "Physical addresses are > unavailable, selecting IOVA as VA mode.\n"); > > + internal_conf->iova_mode =3D RTE_IOVA_VA; > > + rte_eal_get_configuration()->iova_mode =3D > internal_conf->iova_mode; > > + } > > + > > /* if no EAL option "--iova-mode=3D", use bus IOVA scheme = */ > > if (internal_conf->iova_mode =3D=3D RTE_IOVA_DC) { > > /* autodetect the IOVA mapping mode */ > > @@ -1078,12 +1088,6 @@ rte_eal_init(int argc, char **argv) > > if (!RTE_IOVA_IN_MBUF) { > > iova_mode =3D RTE_IOVA_VA; > > RTE_LOG(DEBUG, EAL, "IOVA as VA mode is > forced by build option.\n"); > > - } else if (!phys_addrs) { > > - /* if we have no access to physical > addresses, > > - * pick IOVA as VA mode. > > - */ > > - iova_mode =3D RTE_IOVA_VA; > > - RTE_LOG(DEBUG, EAL, "Physical addresses > are unavailable, selecting IOVA as VA mode.\n"); > > } else if (is_iommu_enabled()) { > > /* we have an IOMMU, pick IOVA as VA mode > */ > > iova_mode =3D RTE_IOVA_VA; > > What tests are you running that generate an error without explicitly > selecting the iova-mode? When I run the fast-tests I see the system > correctly selecting VA without any additional command-line parameters > when running 23.11: > > Hi, we run the tests as they are defined in debian/ubuntu autopkgtest, here a full log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-paelzer-dpdk-23.11= -test-builds/noble/ppc64el/d/dpdk/20231123_134814_ed029@/log.gz Fasttests, just like yours, fail for us. But this is a virtual test env that might not be as powerful as yours. But as I've said, consider this one withdrawn and the one just fixing the test config preferred. > 21:47:05 DPDK_TEST=3Dacl_autotest MALLOC_PERTURB_=3D201 > /home/drc/src/dpdk/build/app/dpdk-test --no-huge -m 2048 > ----------------------------------- output > ----------------------------------- > stdout: > RTE>>acl_autotest > acl context @0x179cbd300 > socket_id=3D-1 > alg=3D5 > first_load_sz=3D0 > max_rules=3D196608 > rule_size=3D128 > num_rules=3D0 > num_categories=3D0 > num_tries=3D0 > acl context @0x179cbd300 > socket_id=3D-1 > alg=3D5 > first_load_sz=3D0 > max_rules=3D196608 > rule_size=3D128 > num_rules=3D0 > num_categories=3D0 > num_tries=3D0 > running test_convert_rules(acl_ipv4vlan_tuple) > running test_convert_rules(acl_ipv4vlan_tuple, > RTE_ACL_FIELD_TYPE_BITMASK type for IPv4) > running test_convert_rules(acl_ipv4vlan_tuple, RTE_ACL_FIELD_TYPE_RANGE > type for IPv4) > running test_convert_rules(acl_ipv4vlan_tuple: swap VLAN and PORTs order) > running test_convert_rules(acl_ipv4vlan_tuple: swap SRC and DST IPv4 orde= r) > test_u32_range#1704 starting range test from 0 to 264192 > Test OK > RTE>> > stderr: > EAL: Detected CPU lcores: 128 > EAL: Detected NUMA nodes: 2 > EAL: Detected static linkage of DPDK > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > EAL: Selected IOVA mode 'VA' > > Dave > --=20 Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd --000000000000e094c2060b5ee8c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 29, 2023 at 10:51=E2=80= =AFPM David Christensen <drc@l= inux.vnet.ibm.com> wrote:


On 11/24/23 2:09 AM, christian.ehrhardt@canonical.com wrote:
> From: David Wilder <dwilder@us.ibm.com>
>
> When using --no-huge option physical address are not guaranteed
> to be persistent.
>
> This change effectively makes "--no-huge" the same as
> "--no-huge --iova-mode=3Dva".
>
> When --no-huge is used (or any other condition making physical
> addresses unavailable) setting --iova-mode=3Dpa will have no effect. >
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com&= gt;
> ---
>=C2=A0 =C2=A0doc/guides/prog_guide/env_abstraction_layer.rst |=C2=A0 9 = ++++++---
>=C2=A0 =C2=A0lib/eal/linux/eal.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 16 ++++= ++++++------
>=C2=A0 =C2=A02 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/gui= des/prog_guide/env_abstraction_layer.rst
> index 6debf54efb..20c7355e0f 100644
> --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> @@ -559,9 +559,12 @@ IOVA Mode is selected by considering what the cur= rent usable Devices on the
>=C2=A0 =C2=A0system require and/or support.
>
>=C2=A0 =C2=A0On FreeBSD, RTE_IOVA_PA is always the default. On Linux, t= he IOVA mode is
> -detected based on a 2-step heuristic detailed below.
> +detected based on a heuristic detailed below.
>
> -For the first step, EAL asks each bus its requirement in terms of IOV= A mode
> +For the first step, if no Physical Addresses are available RTE_IOVA_V= A is
> +selected.
> +
> +Then EAL asks each bus its requirement in terms of IOVA mode
>=C2=A0 =C2=A0and decides on a preferred IOVA mode.
>
>=C2=A0 =C2=A0- if all buses report RTE_IOVA_PA, then the preferred IOVA= mode is RTE_IOVA_PA,
> @@ -575,7 +578,7 @@ and decides on a preferred IOVA mode.
>=C2=A0 =C2=A0If the buses have expressed no preference on which IOVA mo= de to pick, then a
>=C2=A0 =C2=A0default is selected using the following logic:
>
> -- if physical addresses are not available, RTE_IOVA_VA mode is used > +- if enable_iova_as_pa was not set at build RTE_IOVA_VA mode is used<= br> >=C2=A0 =C2=A0- if /sys/kernel/iommu_groups is not empty, RTE_IOVA_VA mo= de is used
>=C2=A0 =C2=A0- otherwise, RTE_IOVA_PA mode is used
>
> diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
> index 57da058cec..2f1fce3c54 100644
> --- a/lib/eal/linux/eal.c
> +++ b/lib/eal/linux/eal.c
> @@ -1067,6 +1067,16 @@ rte_eal_init(int argc, char **argv)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0phys_addrs =3D rte_eal_using_phys_addrs() != =3D 0;
>
> +=C2=A0 =C2=A0 =C2=A0if (!phys_addrs) {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* if we have no acce= ss to physical addresses, pick IOVA as VA mode. */
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (internal_conf->= ;iova_mode =3D=3D RTE_IOVA_PA)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0RTE_LOG(WARNING, EAL, "WARNING: --iova-mode=3Dpa, but Physical = addresses are unavailable, selecting IOVA as VA mode.\n");
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0RTE_LOG(DEBUG, EAL, "Physical addresses are unavailable, select= ing IOVA as VA mode.\n");
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0internal_conf->iov= a_mode =3D RTE_IOVA_VA;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rte_eal_get_configura= tion()->iova_mode =3D internal_conf->iova_mode;
> +=C2=A0 =C2=A0 =C2=A0}
> +
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/* if no EAL option "--iova-mode=3D<= pa|va>", use bus IOVA scheme */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (internal_conf->iova_mode =3D=3D RTE_I= OVA_DC) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* autodetect th= e IOVA mapping mode */
> @@ -1078,12 +1088,6 @@ rte_eal_init(int argc, char **argv)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0if (!RTE_IOVA_IN_MBUF) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0iova_mode =3D RTE_IOVA_VA;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RTE_LOG(DEBUG, EAL, "IOVA as = VA mode is forced by build option.\n");
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0} else if (!phys_addrs) {
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* if we have no access to physical addr= esses,
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * pick IOVA as VA mode.
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0iova_mode =3D RTE_IOVA_VA;
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RTE_LOG(DEBUG, EAL, "Physical addre= sses are unavailable, selecting IOVA as VA mode.\n");
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0} else if (is_iommu_enabled()) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* we have an IOMMU, pick IOVA as = VA mode */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0iova_mode =3D RTE_IOVA_VA;

What tests are you running that generate an error without explicitly
selecting the iova-mode?=C2=A0 When I run the fast-tests I see the system <= br> correctly selecting VA without any additional command-line parameters
when running 23.11:


Hi, we run the tests as they are defin= ed in debian/ubuntu autopkgtest, here a full log:

= =C2=A0https://autopkgtest.ubuntu.com/results/autopkgtest-noble-paelzer-dpd= k-23.11-test-builds/noble/ppc64el/d/dpdk/20231123_134814_ed029@/log.gz<= /div>

Fasttests, just like yours, fail for us.
But this is a virtual test env that might not be as powerful as yours.

But as I've said, consider this one withdrawn and= the one just fixing the test config preferred.


21:47:05 DPDK_TEST=3Dacl_autotest MALLOC_PERTURB_=3D201
/home/drc/src/dpdk/build/app/dpdk-test --no-huge -m 2048
----------------------------------- output
-----------------------------------
stdout:
RTE>>acl_autotest
acl context <acl_ctx>@0x179cbd300
=C2=A0 =C2=A0socket_id=3D-1
=C2=A0 =C2=A0alg=3D5
=C2=A0 =C2=A0first_load_sz=3D0
=C2=A0 =C2=A0max_rules=3D196608
=C2=A0 =C2=A0rule_size=3D128
=C2=A0 =C2=A0num_rules=3D0
=C2=A0 =C2=A0num_categories=3D0
=C2=A0 =C2=A0num_tries=3D0
acl context <acl_ctx>@0x179cbd300
=C2=A0 =C2=A0socket_id=3D-1
=C2=A0 =C2=A0alg=3D5
=C2=A0 =C2=A0first_load_sz=3D0
=C2=A0 =C2=A0max_rules=3D196608
=C2=A0 =C2=A0rule_size=3D128
=C2=A0 =C2=A0num_rules=3D0
=C2=A0 =C2=A0num_categories=3D0
=C2=A0 =C2=A0num_tries=3D0
running test_convert_rules(acl_ipv4vlan_tuple)
running test_convert_rules(acl_ipv4vlan_tuple,
RTE_ACL_FIELD_TYPE_BITMASK type for IPv4)
running test_convert_rules(acl_ipv4vlan_tuple, RTE_ACL_FIELD_TYPE_RANGE type for IPv4)
running test_convert_rules(acl_ipv4vlan_tuple: swap VLAN and PORTs order) running test_convert_rules(acl_ipv4vlan_tuple: swap SRC and DST IPv4 order)=
test_u32_range#1704 starting range test from 0 to 264192
Test OK
RTE>>
stderr:
EAL: Detected CPU lcores: 128
EAL: Detected NUMA nodes: 2
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'

Dave


--
Christian Ehrhardt
Di= rector of Engineering, Ubuntu Server
Canonical Ltd
--000000000000e094c2060b5ee8c3--