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 79199A0547; Fri, 30 Jul 2021 13:11:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 609CC40042; Fri, 30 Jul 2021 13:11:56 +0200 (CEST) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by mails.dpdk.org (Postfix) with ESMTP id 43A4E4003F for ; Fri, 30 Jul 2021 13:11:55 +0200 (CEST) Received: by mail-wr1-f47.google.com with SMTP id d8so10824755wrm.4 for ; Fri, 30 Jul 2021 04:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=saIeT87jyXyF4BJH8/h5bsidM2BtI0IealuDSCGVjQk=; b=jMrQZ3WkjOxrYziRjO4QEbbkeGnuNbJZ18rz2LMmYWfBXMEMcLl1bCYk+Y3QImhhEQ TlkZHR+hkbOgt5gyciPVq3QtPTdZfYGyKuJqeOFDPpQiJlunxNSYq1sGuX0QAQR3bk5V 33NExqN5PcMoTmOo/sQGKlS7ANkk6kvIuBhY6agWXmPu1WyuW2ui21fcBc3YNG9SquE2 SBqgLq3yNxaIkJpZMOo3PzGdjJaqZMPYfePZ9HogA4cQdlqDOn+6lZjCtry7IUp6chuT 2INjrcFbFOxLjik2/c/jHjg/c+TG23KBX26H0XMPorElHLX9B1TJLVtOGn2tWTrHpaFJ OmyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=saIeT87jyXyF4BJH8/h5bsidM2BtI0IealuDSCGVjQk=; b=Ppvzm1bkLrvQ2aaKYoCoAB9ds26vaAJ8B5xBR6teqSPW7rZyuqOMff+5/CS5fwD7yt NW6GO15nojSFXNAgC0/FQSXjR/V1eQeIRH6w8VqiiWXHeQZTbiha+aYTDSDhN3vJtDM+ xzyKcKS33jCzLWoYkxBQTU4s7UA0LFIxc1azl+VNMua2Slsir9fmnaPCbBxxCAKVyiWR rvI72gYzuUcmxGGtlMFwP0muIhPfCzrsPSc3Xx27Lai/lJOpx6VtUPy3E+yTTdiaZBeI lznvhT3Fe9WueNSvGJDGN0HD54AfR7qlNKT0CAUXiBEtFZrye/5h0h0tRk0a5niA42+s akxA== X-Gm-Message-State: AOAM530mToUtn5hHma+jYGXSfIzncnciCKU1C15c/q+j+XGccuObH8Pl Sp5LG7ZLmbVo5Hmpyu+DVvo3nA== X-Google-Smtp-Source: ABdhPJwkv9PLmCjnmCOjSbMioZqve2uyxDGa7UzeQuvloK7/x41ou7V14Hnhhi3NcBS3o9yRL0nrvw== X-Received: by 2002:adf:dd07:: with SMTP id a7mr2352332wrm.377.1627643515081; Fri, 30 Jul 2021 04:11:55 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id s14sm1273946wmc.25.2021.07.30.04.11.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jul 2021 04:11:54 -0700 (PDT) Date: Fri, 30 Jul 2021 13:11:53 +0200 From: Olivier Matz To: Andrew Rybchenko Cc: Mohsin Kazmi , dev@dpdk.org, stable@dpdk.org Message-ID: References: <20210630110404.21209-1-mohsin.kazmi14@gmail.com> <20210707094019.40945-1-mohsin.kazmi14@gmail.com> <0efac6a6-f5d1-48f1-3a95-a8b87469cc23@oktetlabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0efac6a6-f5d1-48f1-3a95-a8b87469cc23@oktetlabs.ru> Subject: Re: [dpdk-dev] [PATCH v3] net: fix Intel-specific Prepare the outer ipv4 hdr for checksum 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 Sender: "dev" 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. > > + } > > + } > > /* > > * Check if headers are fragmented. > > >