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 963944334D for ; Fri, 17 Nov 2023 04:29:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8B120406FF; Fri, 17 Nov 2023 04:29:02 +0100 (CET) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by mails.dpdk.org (Postfix) with ESMTP id A5EA540271 for ; Fri, 17 Nov 2023 04:29:00 +0100 (CET) Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-1cc316ccc38so14150325ad.1 for ; Thu, 16 Nov 2023 19:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1700191740; x=1700796540; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=V3jwji3UyMp80nA45AJE85tof650qLCAb+qgPZNWseo=; b=jj0YuGvFUx1bro7NGgO3XazUzyoXfvcpQ8ByULR9029tMMHGdvSGvXrqG5IFKFFhxN 0yb22htrLlFuIFx8mjcKhQ760/wY1SjeWiHxNx3cvv9FX3dSpQZel+7YhdRFcxxKL5t5 wrbWrLbfXLfVfXEkFt/nctX/l69Hvwjyb6+Bkm6MEGbAAnuTagibs2ZSZ+QZERB5eLdA 7ilhmZR1CoIgZakM8xDLJ1CqsTBPTLg25UwUrna5JqYqToFwtw8/YIgwuVT0N8rZhoMr iceUc3MDkl/YfXBLqXNfa1EBXj+4Ih8KBESyNk5MRsfJT21EUhYXEFyR0PxWpR1yb6YJ 10DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700191740; x=1700796540; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V3jwji3UyMp80nA45AJE85tof650qLCAb+qgPZNWseo=; b=Yo4uoI7WXjZfu7TP4A0KV00hz2GAUUW+CKwB2pAiL0sq7MIl2nJgbqa0zaZp9KogSx RMax8IYTU7KRG4TwKd7XbGyiMIZguNvw9AIe3ikRQlWycnxTI1y4FTJrbc4EujH/NWyY /qCSJI2jKGpit3jZSK1sHhx0bz3khl1P3wf8xy1LuJBH+lZ5G1e9YiZSiAwFhkpCSi7A pNkAiAFtWvJukEJH7dbIjW36sn7K95oZW1JeJdJQ8Dy9D7a/2E4ZmMTMziPaGfDoJyhO n+SkXUt2/mim/CWOZsmqujKvBzGvusVL+ASjInT6/PQnLMw4paqsRQWa1GZcrYmU4ObH 3HBg== X-Gm-Message-State: AOJu0Yw5qvOdgvE4d0PxhQVwGhQ9drjpfVj5OQDxPbPCGXIVuBGT1Coz 2kH2j0P/7y3bX0S5P3cLUQ3PQA== X-Google-Smtp-Source: AGHT+IF948aVE2W3jqWcNdA35YXesYh/+Gfdy7SiW+2FBJPzjhgtL1LaTvHxyoeHFN8lFqdRWq+ozQ== X-Received: by 2002:a17:902:e5c3:b0:1ce:5b6d:e6b1 with SMTP id u3-20020a170902e5c300b001ce5b6de6b1mr1714500plf.17.1700191739665; Thu, 16 Nov 2023 19:28:59 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id y12-20020a170902ed4c00b001cc256ce1besm389963plb.138.2023.11.16.19.28.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Nov 2023 19:28:59 -0800 (PST) Date: Thu, 16 Nov 2023 19:28:57 -0800 From: Stephen Hemminger To: Ferruh Yigit Cc: Kaiwen Deng , dev@dpdk.org, stable@dpdk.org, qiming.yang@intel.com, yidingx.zhou@intel.com, Aman Singh , Yuying Zhang , Olivier Matz , Pablo de Lara Subject: Re: [PATCH] app/test-pmd: fix L4 checksum with padding data Message-ID: <20231116192857.0d49ec5b@hermes.local> In-Reply-To: <7a41467c-c863-4ea1-bf7c-9206bf56aa34@amd.com> References: <20230804082849.533059-1-kaiwenx.deng@intel.com> <892f0567-e1ee-4283-9726-5db1dd92c2cb@amd.com> <20231116145817.78eb0954@hermes.local> <7a41467c-c863-4ea1-bf7c-9206bf56aa34@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Fri, 17 Nov 2023 00:50:16 +0000 Ferruh Yigit wrote: > >> Hi Kaiwen, > >> > >> I am trying to understand the problem, what is the testcase that has > >> checksum error? > >> > >> Are the received mbuf data_len & pkt_len wrong? Instead of trying to fix > >> the mbuf during forwarding, can we fix where packet generated? > > > > The root cause is that get_udptcp_cksum_mbuf is using m->pkt_len > > which maybe larger than the actual data. The real issue is there and > > in rte_ip.h checksum code. The correct fix would be to use l3_len instead. > > > > I see, you are right. > > In 'rte_ipv4_udptcp_cksum_mbuf()', > as payload length "mbuf->pkt_len - l4_off" is used, which includes > padding and if padding is not zero it will end up producing wrong checksum. > > > I agree using 'l3_len' instead is correct fix. > > But this requires ABI/API change, > plus do we have any reason to keep the padding, discarding it as this > patch does is also simpler alternative. Possibly an API version to change the args would work to fix.