From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2114BA052A; Tue, 22 Dec 2020 21:57:49 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 46A25CA57; Tue, 22 Dec 2020 21:57:14 +0100 (CET) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) by dpdk.org (Postfix) with ESMTP id AABB7CAF1 for ; Fri, 18 Dec 2020 18:28:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1608312531; x=1639848531; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=ePAP4OZQD4ml9WYFmk+hhbButHrHfqpjbxGUWH5RHAU=; b=CnAwFUrhqwrkkwt8GDa+tmasMIZPqJ1UgL6lQsFMwjHC4KuZeXAqrF8/ IFoibUYRPPC4rvAESjOVjFrtlIa2zmS/lZ/IjQoGlwUmfKiFurRBP8juq OcqABtdgl8121rbH4g7qBWOroR8nejWoTADXrAWCeCCjExxMLWSW94vEJ 4=; X-Amazon-filename: smime.p7s X-IronPort-AV: E=Sophos;i="5.78,431,1599523200"; d="p7s'?scan'208,217";a="73643422" Thread-Topic: DPDK ENA PMD spurious ierrors Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 18 Dec 2020 17:28:40 +0000 Received: from EX13D08EUB002.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (Postfix) with ESMTPS id 8D1FC282182; Fri, 18 Dec 2020 17:28:38 +0000 (UTC) Received: from EX13D12EUA003.ant.amazon.com (10.43.165.147) by EX13D08EUB002.ant.amazon.com (10.43.166.232) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Dec 2020 17:28:37 +0000 Received: from EX13D12EUA003.ant.amazon.com ([10.43.165.147]) by EX13D12EUA003.ant.amazon.com ([10.43.165.147]) with mapi id 15.00.1497.010; Fri, 18 Dec 2020 17:28:37 +0000 From: "Chauskin, Igor" To: "Roger Melton (rmelton)" , "dev@dpdk.org" , "mw@semihalf.com" , "mk@semihalf.com" , "Tzalik, Guy" Thread-Index: AQHW1AcxAi9dk7fMU061nbCsw7BRt6n9HaRw Date: Fri, 18 Dec 2020 17:28:37 +0000 Message-ID: <93d7b6f154bb4e97a4dd3ffde839ca93@EX13D12EUA003.ant.amazon.com> References: <6BE50C89-4CF5-4CD3-B84D-BDFDAAA62E8F@cisco.com> In-Reply-To: <6BE50C89-4CF5-4CD3-B84D-BDFDAAA62E8F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.166.209] MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 22 Dec 2020 21:57:09 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] DPDK ENA PMD spurious ierrors 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Roger, =20 Thanks for reporting this. Your suggestion seems like a valid = workaround, we=E2=80=99ll work on preparing it. =20 Regards, Igor =20 From: Roger Melton (rmelton) =20 Sent: Thursday, December 17, 2020 01:57 To: dev@dpdk.org; mw@semihalf.com; mk@semihalf.com; Tzalik, Guy = ; Chauskin, Igor Subject: [EXTERNAL] DPDK ENA PMD spurious ierrors =20 CAUTION: This email originated from outside of the organization. Do not = click links or open attachments unless you can confirm the sender and = know the content is safe. =20 We are seeing issues with the DPDK 18.11 ENA PMD incrementing rx_errors = stat on good packets (checksum later validated by software). = We=E2=80=99ve tried several versions from DPDK 18.11 stable, including = 18.11.9 and 18.11.10. Looking through ENA PMD commits, I see there have = been a number of rx stats improvements. Some but not all have been back = ported into DPDK 18.11 stable, some of those presumably because they = depend on updates to the base HW/HAL layer. For example, in the latest = ENA PMD driver, PKT_RX_L4_CKSUM_BAD can only be set if the base layer = has set l4_csum_checked in the RX context, a feature that is not = available in the DPDK 18.11 ENA base driver. =20 Is there a way to avoid incorrectly updating ierrors in DPDK 18.11 that = does not require upgrading the base HW/HAL? For example, if an = application does not enable IPV4, UDP or TCP RX checksum offloads, would = l3_csum_err or l4_csum_err ever be valid? If not, then would it be = valid to pass ena_rx_mbuf_prepare() a pointer to the adapter and check = for l3/l4 checksum errors only if any of DEV_RX_OFFLOAD_*CKSUM are set = in adapter->rte_eth_dev_data->dev_conf.rxmode.offloads? From DPDK = 18.11.10, if RX checksum offloads are not enabled, skip the highlighted = code: =20 static inline void ena_rx_mbuf_prepare(struct rte_mbuf *mbuf, = struct ena_com_rx_ctx *ena_rx_ctx) { uint64_t ol_flags =3D 0; uint32_t packet_type =3D 0; =20 if (ena_rx_ctx->l4_proto =3D=3D ENA_ETH_IO_L4_PROTO_TCP) packet_type |=3D RTE_PTYPE_L4_TCP; else if (ena_rx_ctx->l4_proto =3D=3D = ENA_ETH_IO_L4_PROTO_UDP) packet_type |=3D RTE_PTYPE_L4_UDP; =20 if (ena_rx_ctx->l3_proto =3D=3D = ENA_ETH_IO_L3_PROTO_IPV4) packet_type |=3D RTE_PTYPE_L3_IPV4; else if (ena_rx_ctx->l3_proto =3D=3D = ENA_ETH_IO_L3_PROTO_IPV6) packet_type |=3D RTE_PTYPE_L3_IPV6; =20 if (unlikely(ena_rx_ctx->l4_csum_err)) ol_flags |=3D PKT_RX_L4_CKSUM_BAD; if (unlikely(ena_rx_ctx->l3_csum_err)) ol_flags |=3D PKT_RX_IP_CKSUM_BAD; =20 mbuf->ol_flags =3D ol_flags; mbuf->packet_type =3D packet_type; } =20 While reviewing the code, I also noticed that at the top of the tree, = ierrors are incremented in the transmit path: =20 static int ena_check_and_linearize_mbuf(struct ena_ring *tx_ring, = struct rte_mbuf *mbuf) { struct ena_com_dev *ena_dev; int num_segments, header_len, rc; =20 --- snip --- rc =3D rte_pktmbuf_linearize(mbuf); if (unlikely(rc)) { PMD_DRV_LOG(WARNING, "Mbuf linearize = failed\n"); = rte_atomic64_inc(&tx_ring->adapter->drv_stats->ierrors); ++tx_ring->tx_stats.linearize_failed; return rc; } =20 return rc; } =20 This was introduced by 7830e905b7 net/ena: expose extended stats. =20 Shouldn=E2=80=99t oerrors be incremented in this case? =20 Thanks in advance for your help. =20 Regards, Roger Melton