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 1D4B643349; Thu, 16 Nov 2023 23:58:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 72850402F2; Thu, 16 Nov 2023 23:58:27 +0100 (CET) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by mails.dpdk.org (Postfix) with ESMTP id E162F40150 for ; Thu, 16 Nov 2023 23:58:22 +0100 (CET) Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-6ce2b6cb933so741391a34.0 for ; Thu, 16 Nov 2023 14:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1700175502; x=1700780302; 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=C8u6fmlfXRuMPaChJRJ72Kq+9U+zAw5IHJ9iZqlShAA=; b=j7xsSBg/Xj1Q3NUQUGnhFILiR1CmcN0BvEespxZ3mOPHn8L9pkxHFrjpf10Uua4iP/ h1O514XL1TrP0vJVcWOIvQHXL6VjVU8avOtu3cAhb4bw8uO8tbY1eQGe33QKqN7g3YgI BWw/Zt4JAH0v+1aGmA86TcEr0i1dfIR2hk+NuFkxRWyahiPtG1+dz4QsJ9B/R2MEgKmi hiNLjnEAAHXRGacqErif2Sp/4xNWxqKzEyN7QGtHUZY/qo47HH15areXeDfLdLABtwgf 865iDQ9TRkGKQq4EpeEJHEClCccP6TSvX3xtuvxNxy0yIkF8JqdjQK+E6MCQ6LC1z1ex R5dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700175502; x=1700780302; 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=C8u6fmlfXRuMPaChJRJ72Kq+9U+zAw5IHJ9iZqlShAA=; b=M1Jit3J0byCRPGlAKkh22YqkpnAJnw1AxYkTlZu/8axXq3106T1lEoquUeIQcxpRJv q2NeVgzV9eHKOIstNBVQXLp6Jj415YZ4tZdupdObUk/6wmdKvjNZcB/VX/hM4ON26S3n BFSWKlkwUhFVBJTPnnRoNtaRwJba65FYaKMo7OSgbnNiaYymNkLhA3PEOdlWULgEOUYP YQT1nqeTkYtowueu229Qps7eUKm+28ZuwHcXvLw82B+2+8xjJmqcnfgfzvgMKztFVWN2 yeBfWyuNzbeQ0TuJmYLZml1o9VS4BuUu2Dk/SUWgYRJiWmhWw2o2sNklPZsWOGxnoyU8 Q4BQ== X-Gm-Message-State: AOJu0YyAZ1+PDS5Dujh9z90YV2YcLS4Tjq12/leAAY53mVc/W0BIFnIP P8tROAAZqg8F5eExTe2NVG1dvg== X-Google-Smtp-Source: AGHT+IHMu2PpM0CviiEk2xp+5udrgulhcCnhFTPHgkq6hqHM8kDpQjs3JOxCIRBYTy+Uz6s5+D+ZMg== X-Received: by 2002:a05:6830:104a:b0:6be:e1d6:821b with SMTP id b10-20020a056830104a00b006bee1d6821bmr9623745otp.31.1700175502184; Thu, 16 Nov 2023 14:58:22 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id e14-20020a65688e000000b005c19c586cb7sm177457pgt.33.2023.11.16.14.58.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Nov 2023 14:58:21 -0800 (PST) Date: Thu, 16 Nov 2023 14:58:17 -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: <20231116145817.78eb0954@hermes.local> In-Reply-To: <892f0567-e1ee-4283-9726-5db1dd92c2cb@amd.com> References: <20230804082849.533059-1-kaiwenx.deng@intel.com> <892f0567-e1ee-4283-9726-5db1dd92c2cb@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Thu, 2 Nov 2023 19:20:07 +0000 Ferruh Yigit wrote: > On 8/4/2023 9:28 AM, Kaiwen Deng wrote: > > IEEE 802 packets may have a minimum size limit. The data fields > > should be padded when necessary. In some cases, the padding data > > is not zero. Testpmd does not trim these IP packets to the true > > length of the frame, so errors will occur when calculating TCP > > or UDP checksum. > > > > 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. It also looks like test-pmd is not validating the IP header. Both parse_ipv4() and parse_ipv6() should check if packet was truncated. Same for both UDP and TCP lengths.