From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0058.outbound.protection.outlook.com [104.47.0.58]) by dpdk.org (Postfix) with ESMTP id 0BA121B70D for ; Wed, 16 May 2018 04:08:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1aii+sCYRU5udyT/OPMGV1MHDqmBss2VoJ+q87sArDg=; b=eQhrZyvAptME3ge/gUPHmjeOukzXaesxPGY3SNlsNU5uH0O9hR876olq/XHCROyheT2ySLe4BmuOhzQsN7M5phF6uBj0RXYjd3ZQbHeoqGwVnsxcMBPwW7i3wPkTpHJ28DdIdtFR+P5VOqGwP/0bFzgtAt1OvS0r7hEhbRQ3BUU= Received: from DB7PR08MB3163.eurprd08.prod.outlook.com (52.134.110.149) by DB7PR08MB3227.eurprd08.prod.outlook.com (52.134.111.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Wed, 16 May 2018 02:08:48 +0000 Received: from DB7PR08MB3163.eurprd08.prod.outlook.com ([fe80::59d5:f556:4bdb:bd30]) by DB7PR08MB3163.eurprd08.prod.outlook.com ([fe80::59d5:f556:4bdb:bd30%13]) with mapi id 15.20.0755.018; Wed, 16 May 2018 02:08:48 +0000 From: Gavin Hu To: "dev@dpdk.org" , "Jacob, Jerin" Thread-Topic: dev Digest, Vol 195, Issue 45 Thread-Index: AQHT7CzPc9GD39WiGEeUgMYk/NQAg6QxjR0g Date: Wed, 16 May 2018 02:08:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Gavin.Hu@arm.com; x-originating-ip: [113.29.88.7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR08MB3227; 7:VMcne57urRwVy78k7wwMvMhqWSbA8bwdVln8yFT/m5alg+hc0PRmwW5+cZNqN6jIgL5OM6NrTaLApSNBQQe+CyjGRBAxOHJN/VJnRDANUZJw/nAP1l7FW7w7f7P5yGhZyhh7aexS4VRkBDek3xubl0BHpIE5PfzlH5TKRRjXZYjacrJzjqQUtdpfyg+TeV6egj0hyjNQ5NlnPITQPpcTuYfaqTP5E1FkeH2WSvkp/YScANve5pfUlXbVwPiLlzXM x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB7PR08MB3227; x-ms-traffictypediagnostic: DB7PR08MB3227: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(262104967686372)(66839620246622)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231254)(2232076)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB7PR08MB3227; BCL:0; PCL:0; RULEID:; SRVR:DB7PR08MB3227; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39380400002)(39860400002)(366004)(18543002)(199004)(189003)(27574002)(40434004)(5403001)(13464003)(10533003)(11346002)(476003)(446003)(5250100002)(5890100001)(2501003)(33656002)(7736002)(305945005)(8676002)(81166006)(81156014)(74316002)(68736007)(2906002)(8936002)(5660300001)(110136005)(66066001)(3280700002)(3660700001)(55236004)(316002)(14454004)(6506007)(97736004)(53546011)(102836004)(6246003)(6116002)(3846002)(6436002)(229853002)(7696005)(86362001)(575784001)(59450400001)(25786009)(76176011)(53936002)(72206003)(486006)(105586002)(26005)(6306002)(966005)(53946003)(2900100001)(478600001)(99286004)(55016002)(186003)(9686003)(106356001)(59010400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR08MB3227; H:DB7PR08MB3163.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 8VIf26WgjIqS7/X+g98kC0Z88gr/nSMKSzmfVGYpPGQCKhP4FLoIaS9mgff+qX5U1fdPBV9s+MXeA0iENO7DIn3/PwNOwqSpQmtnvnOi34IWyN75dFBxBiq1bWWhRn1InHGbrUneMq9EyXx+rHu1/1Q1TZtwSJQzPf/ATub5469E3Sbk3uQFMxGgUo5ne+bR6qhBJ8WrKD/WamezVoWvKOeBoArb424FYq9hXLzeIwyLo6h3I4eADJjZyvJIuKNqcrh+5XSt8CLYflRleJTUbO+vFgBeHhWeMYCM7B7Jpe0DdDQIvoEijJxMuGes/cVI spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b049ce0f-3d41-4812-cf7e-08d5bad1f621 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: b049ce0f-3d41-4812-cf7e-08d5bad1f621 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2018 02:08:48.2354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3227 Subject: Re: [dpdk-dev] dev Digest, Vol 195, Issue 45 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 02:08:50 -0000 -----Original Message----- From: dev On Behalf Of dev-request@dpdk.org Sent: Tuesday, May 15, 2018 5:12 PM To: dev@dpdk.org Subject: dev Digest, Vol 195, Issue 45 Send dev mailing list submissions to dev@dpdk.org To subscribe or unsubscribe via the World Wide Web, visit https://dpdk.org/ml/listinfo/dev or, via email, send a message with subject or body 'help' to dev-request@dpdk.org You can reach the person managing the list at dev-owner@dpdk.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of dev digest..." Today's Topics: 1. Re: [PATCH 1/4] app: add LDFLAGS -latomic to link atomic lib (Jerin Jacob) 2. [PATCH v2] net/tap: perform proto field update for tunonly (Vipin Varghese) 3. Re: [PATCH] net/tap: perform proto field update for tun only (Varghese, Vipin) 4. Re: [PATCH 2/4] Driver/Mellanox: fix PMD compiling issue (Jerin Jacob) ---------------------------------------------------------------------- Message: 1 Date: Tue, 15 May 2018 14:37:01 +0530 From: Jerin Jacob To: Gavin Hu Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 1/4] app: add LDFLAGS -latomic to link atomic lib Message-ID: <20180515090700.GA10539@jerin> Content-Type: text/plain; charset=3Dus-ascii -----Original Message----- > Date: Tue, 15 May 2018 04:28:41 -0400 > From: Gavin Hu > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH 1/4] app: add LDFLAGS -latomic to link > atomic lib > X-Mailer: git-send-email 2.1.4 > > For ARM64 platform, libdpdk.a includes the > librte_pmd_octeontx_ssovf.a, which requires the libatomic.a > support.The atomic lib is built-in in the gcc toolchain, but for clang it= has to be explicitly linked. > For more details, please refer to > https://clang.llvm.org/docs/Toolchain.html > > ~/dpdk/build/lib/librte_pmd_octeontx_ssovf.a(timvf_worker.o): In function= `timvf_timer_cancel_burst': > timvf_worker.c:(.text+0x80): undefined reference to `__atomic_fetch_add_8= ' > /home/gavin/arm_repo/dpdk/build/lib/librte_pmd_octeontx_ssovf.a(timvf_wor= ker.o): In function `timvf_timer_arm_burst_sp': > timvf_worker.c:(.text+0x200): undefined reference to `__atomic_fetch_add_= 8' > timvf_worker.c:(.text+0x244): undefined reference to `__atomic_store_2' > timvf_worker.c:(.text+0x278): undefined reference to `__atomic_fetch_add_= 4' > timvf_worker.c:(.text+0x30c): undefined reference to `__atomic_store_2' > > Signed-off-by: Gavin Hu > Reviewed-by: Honnappa Nagarahalli Following patch is part of upstream. Are you testing with following patch/u= pstream. With this patch from Nikhilesh, this __ atomic__ compiling issue was gone. The two patches fix the same issue. Should I abandon my patch? I see this note on: https://clang.llvm.org/docs/Toolchain.html Note Clang does not currently automatically link against libatomic when using li= bgcc_s. You may need to manually add -latomic to support this configuration= when using non-native atomic operations (if you see link errors referring = to __atomic_* functions). commit 55fbc92d7800100628579643c9ee2770614fef10 Author: Pavan Nikhilesh Date: Wed May 9 02:56:00 2018 +0530 event/octeontx: fix build with clang 6 Clang 6 & 7 fail to naturally align packed structs due to this clang can't use 8byte atomic primitives and splits them into lesser atomic primitives. To use lesser atomic primitives we need to link libatomic (-latomic), instead supply alignment attribute to the compiler. timvf_worker.c:(.text+0x498): undefined reference to `__atomic_fetch_ad= d_8' timvf_worker.c:(.text+0x525): undefined reference to `__atomic_store_2' timvf_worker.c:(.text+0x557): undefined reference to `__atomic_fetch_ad= d_4' timvf_worker.c:(.text+0x5de): undefined reference to `__atomic_store_2' Fixes: f874c1eb1519 ("event/octeontx: create and free timer adapter") Reported-by: Andrew Rybchenko Signed-off-by: Pavan Nikhilesh Acked-by: Jerin Jacob > --- > mk/rte.app.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 438f99d..bca8325 > 100644 > --- a/mk/rte.app.mk > +++ b/mk/rte.app.mk > @@ -51,6 +51,7 @@ endif > > # Link only the libraries used in the application LDFLAGS +=3D > --as-needed > +LDFLAGS +=3D -latomic > > # default path for libs > _LDLIBS-y +=3D -L$(RTE_SDK_BIN)/lib > -- > 2.1.4 > ------------------------------ Message: 2 Date: Tue, 15 May 2018 20:19:40 +0530 From: Vipin Varghese To: dev@dpdk.org, keith.wiles@intel.com, ferruh.yigit@intel.com, ophirmu@mellanox.com Cc: Vipin Varghese Subject: [dpdk-dev] [PATCH v2] net/tap: perform proto field update for tunonly Message-ID: <1526395780-105792-1-git-send-email-vipin.varghese@intel.com> The TX function is shared between TAP and TUN PMD. Checking TUN-TAP type field will ensure the TAP PMD will always have protocol field as 0. Signed-off-by: Vipin Varghese Suggested-by: Ferruh Yigit --- Changes in V2: updated in comment wording - Keith Wiles remove debug print from tx code - Keith Wiles --- drivers/net/tap/rte_eth_tap.c | 48 ++++++++++++++++++++++++++-------------= ---- drivers/net/tap/rte_eth_tap.h | 10 +++++++++ 2 files changed, 39 insertions(+), 19 deletions(-) diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c index ea6d899..fafd557 100644 --- a/drivers/net/tap/rte_eth_tap.c +++ b/drivers/net/tap/rte_eth_tap.c @@ -115,7 +115,8 @@ tun_alloc(struct pmd_internals *pmd) * Do not set IFF_NO_PI as packet information header will be needed * to check if a received packet has been truncated. */ -ifr.ifr_flags =3D (tap_type) ? IFF_TAP : IFF_TUN | IFF_POINTOPOINT; +ifr.ifr_flags =3D (pmd->type =3D=3D ETH_TUNTAP_TYPE_TAP) ? +IFF_TAP : IFF_TUN | IFF_POINTOPOINT; snprintf(ifr.ifr_name, IFNAMSIZ, "%s", pmd->name); TAP_LOG(DEBUG, "ifr_name '%s'", ifr.ifr_name); @@ -502,20 +503,22 @@ pmd_tx_burst(void *queue, struct rte_mbuf **bufs, uin= t16_t nb_pkts) if (rte_pktmbuf_pkt_len(mbuf) > max_size) break; -/* - * TUN and TAP are created with IFF_NO_PI disabled. - * For TUN PMD this mandatory as fields are used by - * Kernel tun.c to determine whether its IP or non IP - * packets. - * - * The logic fetches the first byte of data from mbuf. - * compares whether its v4 or v6. If none matches default - * value 0x00 is taken for protocol field. - */ -char *buff_data =3D rte_pktmbuf_mtod(seg, void *); -j =3D (*buff_data & 0xf0); -pi.proto =3D (j =3D=3D 0x40) ? 0x0008 : -(j =3D=3D 0x60) ? 0xdd86 : 0x00; +if (txq->type =3D=3D ETH_TUNTAP_TYPE_TUN) { +/* + * TUN and TAP are created with IFF_NO_PI disabled. + * For TUN PMD this mandatory as fields are used by + * Kernel tun.c to determine whether its IP or non IP + * packets. + * + * The logic fetches the first byte of data from mbuf + * then compares whether its v4 or v6. If first byte + * is 4 or 6, then protocol field is updated. + */ +char *buff_data =3D rte_pktmbuf_mtod(seg, void *); +j =3D (*buff_data & 0xf0); +pi.proto =3D (j =3D=3D 0x40) ? 0x0008 : +(j =3D=3D 0x60) ? 0xdd86 : 0x00; +} iovecs[0].iov_base =3D π iovecs[0].iov_len =3D sizeof(pi); @@ -1052,6 +1055,9 @@ tap_setup_queue(struct rte_eth_dev *dev, tx->mtu =3D &dev->data->mtu; rx->rxmode =3D &dev->data->dev_conf.rxmode; +tx->type =3D pmd->type; +rx->type =3D pmd->type; + return *fd; } @@ -1386,6 +1392,7 @@ eth_dev_tap_create(struct rte_vdev_device *vdev, char= *tap_name, pmd =3D dev->data->dev_private; pmd->dev =3D dev; snprintf(pmd->name, sizeof(pmd->name), "%s", tap_name); +pmd->type =3D ETH_TUNTAP_TYPE_UNKNOWN; pmd->ioctl_sock =3D socket(AF_INET, SOCK_DGRAM, 0); if (pmd->ioctl_sock =3D=3D -1) { @@ -1421,7 +1428,9 @@ eth_dev_tap_create(struct rte_vdev_device *vdev, char= *tap_name, pmd->txq[i].fd =3D -1; } -if (tap_type) { +pmd->type =3D (tap_type) ? ETH_TUNTAP_TYPE_TAP : ETH_TUNTAP_TYPE_TUN; + +if (pmd->type =3D=3D ETH_TUNTAP_TYPE_TAP) { if (is_zero_ether_addr(mac_addr)) eth_random_addr((uint8_t *)&pmd->eth_addr); else @@ -1440,7 +1449,7 @@ eth_dev_tap_create(struct rte_vdev_device *vdev, char= *tap_name, if (tap_ioctl(pmd, SIOCSIFMTU, &ifr, 1, LOCAL_AND_REMOTE) < 0) goto error_exit; -if (tap_type) { +if (pmd->type =3D=3D ETH_TUNTAP_TYPE_TAP) { memset(&ifr, 0, sizeof(struct ifreq)); ifr.ifr_hwaddr.sa_family =3D AF_LOCAL; rte_memcpy(ifr.ifr_hwaddr.sa_data, &pmd->eth_addr, @@ -1812,7 +1821,9 @@ rte_pmd_tap_remove(struct rte_vdev_device *dev) struct pmd_internals *internals; int i; -TAP_LOG(DEBUG, "Closing TUN/TAP Ethernet device on numa %u", +internals =3D eth_dev->data->dev_private; +TAP_LOG(DEBUG, "Closing %s Ethernet device on numa %u", +(internals->type =3D=3D ETH_TUNTAP_TYPE_TAP) ? "TAP" : "TUN", rte_socket_id()); /* find the ethdev entry */ @@ -1820,7 +1831,6 @@ rte_pmd_tap_remove(struct rte_vdev_device *dev) if (!eth_dev) return 0; -internals =3D eth_dev->data->dev_private; if (internals->nlsk_fd) { tap_flow_flush(eth_dev, NULL); tap_flow_implicit_flush(internals, NULL); diff --git a/drivers/net/tap/rte_eth_tap.h b/drivers/net/tap/rte_eth_tap.h index 67c9d4b..8b0da5a 100644 --- a/drivers/net/tap/rte_eth_tap.h +++ b/drivers/net/tap/rte_eth_tap.h @@ -23,6 +23,13 @@ #define RTE_PMD_TAP_MAX_QUEUES1 #endif +enum rte_tuntap_type { +ETH_TUNTAP_TYPE_UNKNOWN, +ETH_TUNTAP_TYPE_TUN, +ETH_TUNTAP_TYPE_TAP, +ETH_TUNTAP_TYPE_MAX, +}; + struct pkt_stats { uint64_t opackets; /* Number of output packets */ uint64_t ipackets; /* Number of input packets */ @@ -38,6 +45,7 @@ struct rx_queue { uint32_t trigger_seen; /* Last seen Rx trigger value */ uint16_t in_port; /* Port ID */ int fd; +int type; /* Type field - TUN|TAP */ struct pkt_stats stats; /* Stats for this RX queue */ uint16_t nb_rx_desc; /* max number of mbufs available */ struct rte_eth_rxmode *rxmode; /* RX features */ @@ -48,6 +56,7 @@ struct rx_queue { struct tx_queue { int fd; +int type; /* Type field - TUN|TAP */ uint16_t *mtu; /* Pointer to MTU from dev_data */ uint16_t csum:1; /* Enable checksum offloading */ struct pkt_stats stats; /* Stats for this TX queue */ @@ -57,6 +66,7 @@ struct pmd_internals { struct rte_eth_dev *dev; /* Ethernet device. */ char remote_iface[RTE_ETH_NAME_MAX_LEN]; /* Remote netdevice name */ char name[RTE_ETH_NAME_MAX_LEN]; /* Internal Tap device name */ +int type; /* Type field - TUN|TAP */ struct ether_addr eth_addr; /* Mac address of the device port */ struct ifreq remote_initial_flags; /* Remote netdevice flags on init */ int remote_if_index; /* remote netdevice IF_INDEX */ -- 2.7.4 ------------------------------ Message: 3 Date: Tue, 15 May 2018 09:08:49 +0000 From: "Varghese, Vipin" To: "Wiles, Keith" Cc: "dev@dpdk.org" , "ophirmu@mellanox.com" , "Yigit, Ferruh" Subject: Re: [dpdk-dev] [PATCH] net/tap: perform proto field update for tun only Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D1EB6B2@BGSMSX101.gar.corp.intel.com> Content-Type: text/plain; charset=3D"utf-8" Thanks Keith, I have made changes and shared v2 patch for both the suggestions. Thanks Vipin Varghese > > +/* > > + * TUN and TAP are created with IFF_NO_PI disabled. > > + * For TUN PMD this mandatory as fields are used by > > + * Kernel tun.c to determine whether its IP or non IP > > + * packets. > > + * > > + * The logic fetches the first byte of data from mbuf. > > + * compares whether its v4 or v6. If none match default > > + * value 0x00 is taken for protocol field. > > Little reword and remove the ?.? at end of first line. > > The logic fetches the first byte of data from mbuf then compares whether = it is v4 > or v6. If not equal to zero then it must be a protocol field. > > > > > + */ > > +char *buff_data =3D rte_pktmbuf_mtod(seg, void *); > > +j =3D (*buff_data & 0xf0); > > +pi.proto =3D (j =3D=3D 0x40) ? 0x0008 : > > +(j =3D=3D 0x60) ? 0xdd86 : 0x00; > > +printf("j %x pi proto %x\n", j, pi.proto); > > Should this not be a LOG message or is this debug that was not removed? I= f log > message then add move text to explain the output better. > ------------------------------ Message: 4 Date: Tue, 15 May 2018 14:41:42 +0530 From: Jerin Jacob To: Gavin Hu Cc: dev@dpdk.org, Sirshak Das Subject: Re: [dpdk-dev] [PATCH 2/4] Driver/Mellanox: fix PMD compiling issue Message-ID: <20180515091141.GB10539@jerin> Content-Type: text/plain; charset=3Dus-ascii -----Original Message----- > Date: Tue, 15 May 2018 04:28:42 -0400 > From: Gavin Hu > To: dev@dpdk.org > CC: Sirshak Das > Subject: [dpdk-dev] [PATCH 2/4] Driver/Mellanox: fix PMD compiling issue > X-Mailer: git-send-email 2.1.4 Please add the reason and compilation error log. and make sure to fix check patch.sh and check-gitlog.sh errors. Sure I will rework and submit a V3 patch. Thanks for your comments. > > Signed-off-by: Gavin Hu > Signed-off-by: Sirshak Das > Reviewed-by: Phil Yang > Reviewed-by: Honnappa Nagarahalli > --- > drivers/net/mlx5/mlx5_rxtx_vec_neon.h | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_neon.h b/drivers/net/mlx5/mlx= 5_rxtx_vec_neon.h > index 2673d6b..71a5eaf 100644 > --- a/drivers/net/mlx5/mlx5_rxtx_vec_neon.h > +++ b/drivers/net/mlx5/mlx5_rxtx_vec_neon.h > @@ -167,8 +167,8 @@ txq_scatter_v(struct mlx5_txq_data *txq, struct rte_m= buf **pkts, > vst1q_u8((void *)t_wqe, ctrl); > /* Fill ESEG in the header. */ > vst1q_u16((void *)(t_wqe + 1), > - (uint16x8_t) { 0, 0, cs_flags, rte_cpu_to_be_16(len), > - 0, 0, 0, 0 }); > + ((uint16x8_t) { 0, 0, cs_flags, rte_cpu_to_be_16(len), > + 0, 0, 0, 0 })); > txq->wqe_ci =3D wqe_ci; > } > if (!n) > @@ -300,10 +300,10 @@ txq_burst_v(struct mlx5_txq_data *txq, struct rte_m= buf **pkts, uint16_t pkts_n, > vst1q_u8((void *)t_wqe, ctrl); > /* Fill ESEG in the header. */ > vst1q_u8((void *)(t_wqe + 1), > - (uint8x16_t) { 0, 0, 0, 0, > -cs_flags, 0, 0, 0, > -0, 0, 0, 0, > -0, 0, 0, 0 }); > + ((uint8x16_t) { 0, 0, 0, 0, > + cs_flags, 0, 0, 0, > + 0, 0, 0, 0, > + 0, 0, 0, 0 })); > #ifdef MLX5_PMD_SOFT_COUNTERS > txq->stats.opackets +=3D pkts_n; > #endif > -- > 2.1.4 > End of dev Digest, Vol 195, Issue 45 ************************************ IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.