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 CDBBDA0032; Fri, 29 Oct 2021 10:29:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 703B5410E0; Fri, 29 Oct 2021 10:29:09 +0200 (CEST) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by mails.dpdk.org (Postfix) with ESMTP id 0B99240688 for ; Fri, 29 Oct 2021 10:29:08 +0200 (CEST) Received: by mail-wr1-f53.google.com with SMTP id p14so14916767wrd.10 for ; Fri, 29 Oct 2021 01:29:08 -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:content-transfer-encoding:in-reply-to; bh=5dlx5BJth9EYwCRDOpIbzZl6FO9SORZoRDSa16+hC5I=; b=M2YDbKVkRyG5KS2/MwAkskSqCo5fBZ7VgDXAa2RID8rLFjE3B345F09ZZ+mFaRDX0w WSH6TImXMdM1TB/+Oo5hF+9tx5kANOQ816z5FK/4CgiU20OYjB16qyQWtf9yljEQO7Ng nxqLV6lOdNf8oLFir/ytUytpCe/bsvNbYRAzNM4p0yWUwdIsRBgi4aCRsxAVVqNrywRS o7JMLYhGXptBDufSylvHcwZT9IxZqX3az+UFKWRfDuUyGZdsYlgvXmolGxTIfbEzGjpp V0qEjKspIDq6l+zdqn/IQr7wUvc0BwRvakdaTbqSbzOyuDPOE9+pFqxbHlaLBfEJ1MXl NnTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=5dlx5BJth9EYwCRDOpIbzZl6FO9SORZoRDSa16+hC5I=; b=IyJNnaB+KYa1Nu0m4CtN6TdFlcOc5VgyXQXp0gRdlWFvgE3yH1jKLqv+s9Afh5KjLb gxXGHLwKRYifF57gThKBaF/29uPZdrVEK7GJ4whsTNRqcpgqV2qBMnK93aWGfa+HFiy0 /jovS96hWdVUMcx+By6l39PZiP7CflF9HBElgV3cqfOYMdBRyBk1hW6wNEdTKCLjqVkw 7q8xBJ/ZALcZpwMF21nlwb2uo4IjUR5/cGrWvJkzY3Jbl8IwoGSARZ88DJqhc5qBLEtT zSeXLBDE8IFd+e4jqQlWcU3iTyLTszkhChYh7EdkzXlOpaLnbHbBBbRM1zkY8rUtx1uW 7T7Q== X-Gm-Message-State: AOAM532WVpnW/j2H4JMjyM6gSrXCNTdQ+Fjda2slhzG4uY5vPqybehUw UD9lSQg8k1m8UayrUPgEPHRgqA== X-Google-Smtp-Source: ABdhPJx0cLYJrDr0gXcBxs+Ta6Ld70Mqe4CrjMow/hkBnIRsoAZ0qoitbSVoYtb/4+tyxkyZlaFXtA== X-Received: by 2002:a05:6000:15cc:: with SMTP id y12mr12698362wry.333.1635496147714; Fri, 29 Oct 2021 01:29:07 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id w14sm4265298wmi.37.2021.10.29.01.29.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Oct 2021 01:29:06 -0700 (PDT) Date: Fri, 29 Oct 2021 10:29:04 +0200 From: Olivier Matz To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Ferruh Yigit , Xiaoyun Li , konstantin.ananyev@intel.com, stephen@networkplumber.org, dev@dpdk.org, stable@dpdk.org, Vladimir Medvedkin Message-ID: References: <20211015051306.320328-1-xiaoyun.li@intel.com> <20211020101243.203063-1-xiaoyun.li@intel.com> <66ba870b-947f-29aa-45da-0e6f930b2398@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D86C6A@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86C6A@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] [PATCH v3] app/testpmd: fix l4 sw csum over multi segments 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, Oct 27, 2021 at 01:29:52PM +0200, Morten Brørup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit > > Sent: Wednesday, 27 October 2021 12.49 > > > > On 10/20/2021 11:12 AM, Xiaoyun Li wrote: > > > In csum forwarding mode, software UDP/TCP csum calculation only takes > > > the first segment into account while using the whole packet length so > > > the calculation will read invalid memory region with multi-segments > > > packets and will get wrong value. > > > This patch fixes this issue. > > > > > > Fixes: af75078fece3 ("first public release") > > > Cc: stable@dpdk.org > > > > > > Signed-off-by: Xiaoyun Li > > > --- > > > v3: > > > * Use rte_raw_cksum() for multi-segs case instead of copying the > > whole > > > * packet. > > > v2: > > > * Use static stack memory instead of dynamic allocating in datapath > > > --- > > > app/test-pmd/csumonly.c | 68 ++++++++++++++++++++++++++++++++------ > > --- > > > 1 file changed, 53 insertions(+), 15 deletions(-) > > > > > > diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c > > > index 090797318a..f3e60eb3c3 100644 > > > --- a/app/test-pmd/csumonly.c > > > +++ b/app/test-pmd/csumonly.c > > > @@ -91,12 +91,41 @@ struct simple_gre_hdr { > > > } __rte_packed; > > > > > > static uint16_t > > > -get_udptcp_checksum(void *l3_hdr, void *l4_hdr, uint16_t ethertype) > > > +get_udptcp_checksum(void *l3_hdr, struct rte_mbuf *m, uint16_t > > l4_off, > > > + uint16_t ethertype) > > > { > > > + uint16_t off = l4_off; > > > + uint32_t cksum = 0; > > > + char *buf; > > > + > > > + while (m != NULL) { > > > + buf = rte_pktmbuf_mtod_offset(m, char *, off); > > > + cksum += rte_raw_cksum(buf, m->data_len - off); > > > + off = 0; > > > + m = m->next; > > > + } > > > if (ethertype == _htons(RTE_ETHER_TYPE_IPV4)) > > > - return rte_ipv4_udptcp_cksum(l3_hdr, l4_hdr); > > > + cksum += rte_ipv4_phdr_cksum(l3_hdr, 0); > > > else /* assume ethertype == RTE_ETHER_TYPE_IPV6 */ > > > - return rte_ipv6_udptcp_cksum(l3_hdr, l4_hdr); > > > + cksum += rte_ipv6_phdr_cksum(l3_hdr, 0); > > > + > > > > Hi Xiaoyun, > > > > I can see 'rte_ipv[46]_udptcp_cksum()' is not taking multi segment mbuf > > into account, so this fix is required, > > but instead of implementing this logic into testpmd, what do you think > > to have APIs to support multi segment mbufs? > > This way other applications also benefit from it and we don't need to > > maintain ip4/6 checksum related code in testpmd. > > +1 > > Also, there is no need to implement the multi-segment raw checksum loop in test-pmd. > > You can use the multi-segment raw checksum function in the net library instead: > http://code.dpdk.org/dpdk/latest/source/lib/net/rte_ip.h#L224 +1 We can have mbuf variants of udptcp checksum functions: rte_ipv4_udptcp_cksum() rte_ipv4_udptcp_cksum_verify() rte_ipv6_udptcp_cksum() rte_ipv6_udptcp_cksum_verify() Adding a "_mbuf" suffix would be consistent with rte_raw_cksum_mbuf(). Olivier