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 75305A052A; Tue, 22 Dec 2020 21:58:08 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D4588CA3A; Tue, 22 Dec 2020 21:57:15 +0100 (CET) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by dpdk.org (Postfix) with ESMTP id 000AFCADB for ; Fri, 18 Dec 2020 22:28:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1608326926; x=1639862926; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=tMvEZTAR017XhYCN4mJznlmRiqB+U6GQXFROI6peWNU=; b=M0CfHtG9hNUWo+F1q8m2n26Hm5L7/OYe3aivf+3iZUZix5gE8FhK0lmK 8UxYxKOHwPROGjKU7cbJKdhi1b6EXVoUxvqS5N1n9AHMrC7xdOg1y+eQw hwwJFeLZT7sgt9VDVM8kK45miCMgxOPJBKNShUaWfxaBVShh7iXRCAJZ0 c=; X-Amazon-filename: smime.p7s X-IronPort-AV: E=Sophos;i="5.78,431,1599523200"; d="p7s'?scan'208,217";a="97318612" Thread-Topic: DPDK ENA PMD spurious ierrors Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-c7c08562.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 18 Dec 2020 21:28:37 +0000 Received: from EX13D08EUB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-1e-c7c08562.us-east-1.amazon.com (Postfix) with ESMTPS id B87DC240BA0; Fri, 18 Dec 2020 21:28:35 +0000 (UTC) Received: from EX13D12EUA003.ant.amazon.com (10.43.165.147) by EX13D08EUB001.ant.amazon.com (10.43.166.236) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Dec 2020 21:28:34 +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 21:28:34 +0000 From: "Chauskin, Igor" To: "Roger Melton (rmelton)" , "dev@dpdk.org" , "mw@semihalf.com" , "mk@semihalf.com" , "Tzalik, Guy" Thread-Index: AQHW1AcxAi9dk7fMU061nbCsw7BRt6n9HaRw///AKYCAAILWcA== Date: Fri, 18 Dec 2020 21:28:34 +0000 Message-ID: References: <6BE50C89-4CF5-4CD3-B84D-BDFDAAA62E8F@cisco.com> <93d7b6f154bb4e97a4dd3ffde839ca93@EX13D12EUA003.ant.amazon.com> <5DC8CBD9-63F5-49ED-93F9-866137B7DAC4@cisco.com> In-Reply-To: <5DC8CBD9-63F5-49ED-93F9-866137B7DAC4@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 We plan to address both issues. =20 Thanks, Igor =20 From: Roger Melton (rmelton) =20 Sent: Friday, December 18, 2020 20:37 To: Chauskin, Igor ; dev@dpdk.org; mw@semihalf.com; = mk@semihalf.com; Tzalik, Guy Subject: RE: [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 Hi Igor, =20 Thanks for the reply. By work on preparing it do you mean that you plan = to: =20 1. check rxmode.offloads in ena_rx_mbuf_prepare() before setting = PKT_RX_[L3,L4]_CKSUM_BAD bits in ol_flags, and=20 2. increment oerrors instead of ierrors in the TX path? =20 FWIW, Since we do not enable hardware checksum offloads and since our = application validates L3/L4 ingress checksums, our workaround in DPDK = 18.11.10 is to eliminate incrementing ierrors. There=E2=80=99s no point = in wasting cycles. =20 Regards, Roger =20 =20 =20 From: "Chauskin, Igor" > Date: Friday, December 18, 2020 at 12:29 PM To: "Roger Melton (rmelton)" >, "dev@dpdk.org " = >, "mw@semihalf.com = " >, = "mk@semihalf.com " >, "Tzalik, Guy" > Subject: RE: DPDK ENA PMD spurious ierrors =20 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