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 1A0FFA04FD; Thu, 10 Nov 2022 11:29:50 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 032AB40150; Thu, 10 Nov 2022 11:29:50 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 2ADE2400EF for ; Thu, 10 Nov 2022 11:29:49 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B47665C01F0; Thu, 10 Nov 2022 05:29:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 10 Nov 2022 05:29:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1668076188; x= 1668162588; bh=CH811cA6DqJtJR6Zprj5hONxdWemJRpkRmbhEyA1RAo=; b=M qEN82nvY9NQzavhIv8H9+g9PnWUUThOTCOimGZBUCFS67H0a1j9Ksq3kBKhJWZFC pMqS4vwS/NvRC6OGRv99jWbAdK0qWcristvSGaLluLC/G0kP1fvUlx7HFoJXivx4 Lu2U6aOtUeu3/85LyCtXwLfLJ4EL3hLPxH3qRPHmBqa32jF27iU4tn20TUUr5elm oAcm+wNQXGIWS0nSO+pw3OlnLjtGA9W99G9zYI84ufOwxBvA/4P4nn0G8u56Yjns FPQ583TN+Xsm+oU5bVgCN1wpyWfZa4DkkmlUOtC1b0LDE7ikuwmnrWc1FYv8vV2Q oL9w/aMqqJS97s1827jfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1668076188; x= 1668162588; bh=CH811cA6DqJtJR6Zprj5hONxdWemJRpkRmbhEyA1RAo=; b=p yjfpu1ecDGmUsL1Oom6xxslStGTkDd6oHSMYBNcq0YhaXivfueZH5egi4dcZRHcP 1xGRgvrV+LocPfrPmpdWuZy/wbE3h0g2hTS1N9TaIU5cl19Tent8r8HHW/g+LoUS ayKXUOtZUHAniZZ7eL1Wa5kHzG2z+BKGwEA0SzUK/xlIbEghOvXd5SQjQPdwzpHW 6SdWdDRfFrNAWr0wR4/kfptRMOIzHpJoU83KMRtjIZBxpXHCKKPiIKSb+mdhyElg 54jsoeCjZYHw6ReQqgm2/1IMPikpQSOxwrRxYvhSwMEShfVzyh7ik5xaMsJ8H7F+ YVEDsYAKOFH6m+iKxT5fg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeeggdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfefhjeeluedvvedtuddtuedtvefhieejtefhffeujefhteduudev tdektdeikeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Nov 2022 05:29:47 -0500 (EST) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= , Andrew Rybchenko Cc: dev@dpdk.org, Olivier Matz , "Ananyev, Konstantin" , Stephen Hemminger , Jerin Jacob Kollanukkaran , Ferruh Yigit , David Marchand Subject: Re: Is it correct to report checksum good when there is no checksum? Date: Thu, 10 Nov 2022 11:29:46 +0100 Message-ID: <151644712.GCLyqPZtNA@thomas> In-Reply-To: References: <8bea1ef1-1977-f24f-f549-0c2126c23e3c@oktetlabs.ru> <98CBD80474FA8B44BF855DF32C47DC35D874AA@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 10/11/2022 11:08, Andrew Rybchenko: > On 11/10/22 12:55, Morten Br=F8rup wrote: > >> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru] > >> Sent: Thursday, 10 November 2022 10.26 > >> > >> Hi all, > >> > >> some drivers report RTE_MBUF_F_RX_IP_CKSUM_GOOD for IPv6 packets. > >> For me it looks strange, but I see some technical reasons behind. > >=20 > > Please note: IPv6 packets by definition have no IP checksum. > >=20 > >> Documentation in lib/mbuf/rte_mbuf_core.h is a bit vague. > >> Should UNKNOWN or NONE be used instead? > >=20 > > Certainly not NONE. Its description says: "the IP checksum is *not* cor= rect in the packet [...]". But there is no incorrect IP checksum in the pac= ket. > >=20 >=20 > Thanks, I should read the definition of none more careful. >=20 > > I will argue against UNKNOWN. Its description says: "no information abo= ut the RX IP checksum". But we do have information about it! We know that t= he IP checksum is not there (the value is "NULL"), and that it is not suppo= sed to be there (the value is supposed to be "NULL"). > >=20 >=20 > I thought that "no checksum" =3D> "no information" =3D> UNKNOWN >=20 > > So I consider GOOD the correct response here. > >=20 > > GOOD also means that the application can proceed processing the packet = normally without further IP header checksum checking, so it's good for perf= ormance. > >=20 >=20 > It is very important point and would be nice to have in GOOD > case definition (both IP and L4 cases). It is the right > motivation why GOOD makes sense for IPv6. >=20 > > It should be added to the description of RTE_MBUF_F_RX_IP_CKSUM_GOOD th= at IPv6 packets always return this value, because IPv6 packets have no IP h= eader checksum, and that is what is expected of them. >=20 > Could you make a patch? That would be perfect. I agree to use GOOD for IPv6 checksum. > Bonus question is UDP checksum 0 case. GOOD as well? > (just want to clarify the documentation while we're on it). Good question :)