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 4E92CA0A0C for ; Sat, 31 Jul 2021 14:49:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4495840DDC; Sat, 31 Jul 2021 14:49:07 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 042F940042; Sat, 31 Jul 2021 14:49:05 +0200 (CEST) Received: from [192.168.100.116] (unknown [37.139.99.76]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 69AE27F50B; Sat, 31 Jul 2021 15:49:04 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 69AE27F50B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1627735744; bh=aeRUyeskHthGReOUentoNmebRQALWufii86uCGW5KJM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=lo/qPUsEVO5cnQ3DCBhc8O8ajju3MoK1gq1GXhUPd6vUEsYsetlVJrYGW2qGHiz3q XGVq5LzCwXKVvOi8+yicT7PXXZ6DIOF4kMDmmWDYShXVlvtVtfCnmeyU9nb1OBGRU9 5dJ6fO8bHe7nyziUOLDug5KpXRhv9VQMugX+RBrE= To: Olivier Matz Cc: Mohsin Kazmi , dev@dpdk.org, stable@dpdk.org References: <20210630110404.21209-1-mohsin.kazmi14@gmail.com> <20210707094019.40945-1-mohsin.kazmi14@gmail.com> <0efac6a6-f5d1-48f1-3a95-a8b87469cc23@oktetlabs.ru> From: Andrew Rybchenko Message-ID: <6d7c41bf-6e9f-8fbd-bfc8-11ca07c777d8@oktetlabs.ru> Date: Sat, 31 Jul 2021 15:49:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] net: fix Intel-specific Prepare the outer ipv4 hdr for checksum X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 7/30/21 2:11 PM, Olivier Matz wrote: > On Wed, Jul 28, 2021 at 06:46:53PM +0300, Andrew Rybchenko wrote: >> On 7/7/21 12:40 PM, Mohsin Kazmi wrote: >>> Preparation the headers for the hardware offload >>> misses the outer ipv4 checksum offload. >>> It results in bad checksum computed by hardware NIC. >>> >>> This patch fixes the issue by setting the outer ipv4 >>> checksum field to 0. >>> >>> Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Mohsin Kazmi >>> Acked-by: Qi Zhang >>> --- >>> v3: >>> * Update the conditional test with PKT_TX_OUTER_IP_CKSUM. >>> * Update the commit title with "Intel-specific". >>> >>> v2: >>> * Update the commit message with Fixes. >>> >>> lib/net/rte_net.h | 15 +++++++++++++-- >>> 1 file changed, 13 insertions(+), 2 deletions(-) >>> >>> diff --git a/lib/net/rte_net.h b/lib/net/rte_net.h >>> index 434435ffa2..3f4c8c58b9 100644 >>> --- a/lib/net/rte_net.h >>> +++ b/lib/net/rte_net.h >>> @@ -125,11 +125,22 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf *m, uint64_t ol_flags) >>> * Mainly it is required to avoid fragmented headers check if >>> * no offloads are requested. >>> */ >>> - if (!(ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_L4_MASK | PKT_TX_TCP_SEG))) >>> + if (!(ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_L4_MASK | PKT_TX_TCP_SEG | >>> + PKT_TX_OUTER_IP_CKSUM))) >>> return 0; >>> - if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6)) >>> + if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6)) { >>> inner_l3_offset += m->outer_l2_len + m->outer_l3_len; >>> + /* >>> + * prepare outer ipv4 header checksum by setting it to 0, >>> + * in order to be computed by hardware NICs. >>> + */ >>> + if (ol_flags & PKT_TX_OUTER_IP_CKSUM) { >>> + ipv4_hdr = rte_pktmbuf_mtod_offset(m, >>> + struct rte_ipv4_hdr *, m->outer_l2_len); >>> + ipv4_hdr->hdr_checksum = 0; >> >> Here we assume that the field is located in the first segment. >> Unlikely but it still could be false. We must handle it properly. > > This is specified in the API comment, so I think it has to be checked > by the caller. If no, what's the point to spoil memory here if stricter check is done few lines below. >>> + } >>> + } >>> /* >>> * Check if headers are fragmented. >>> >>