From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> 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 <dev@dpdk.org>; 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: <xms:nNJsYxxokdfF9f27OOLRUuTL5n4nDqlmc4kXDzFhTGtPnggF-Pnjyw> <xme:nNJsYxSYOPYF3gUJZoD6gewdF7RqSUfA7kHl-zFfVrBdFNgl_ze8A7AuOtKcDUvLd _-nSSAm1qb4ZhzavQ> X-ME-Received: <xmr:nNJsY7UQizB3B_YhDt_StGwNP0yrqDy64ItHZco-Dbyap2SM3v0cwHgILdQD7etiESXhY6XX4iS0NzD5HrG8jS2fgA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeeggdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfefhjeeluedvvedtuddtuedtvefhieejtefhffeujefhteduudev tdektdeikeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: <xmx:nNJsYzgn-D159ZixHumJamoFdJMsvYy09fb3ezxK4OBthJsaRgnbKw> <xmx:nNJsYzDHyEkC37EdoW8-ZvRz7z9ShvleHl-n9R9pnPD_gvewkqEYLQ> <xmx:nNJsY8KLmI6tub-7_oeTapyTPD3-s-RZ0sxhl6zGNlGDTryCUUHuBw> <xmx:nNJsY1BPCFGqeXt1Vp3BK2a3ZifJDn4VK8NXIUB6rYTHjxdro2llSA> Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Nov 2022 05:29:47 -0500 (EST) From: Thomas Monjalon <thomas@monjalon.net> To: Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> Cc: dev@dpdk.org, Olivier Matz <olivier.matz@6wind.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Stephen Hemminger <stephen@networkplumber.org>, Jerin Jacob Kollanukkaran <jerinj@marvell.com>, Ferruh Yigit <ferruh.yigit@amd.com>, David Marchand <david.marchand@redhat.com> 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: <b663f8ab-5a5e-c3a2-5abc-fee7e8216d24@oktetlabs.ru> References: <8bea1ef1-1977-f24f-f549-0c2126c23e3c@oktetlabs.ru> <98CBD80474FA8B44BF855DF32C47DC35D874AA@smartserver.smartshare.dk> <b663f8ab-5a5e-c3a2-5abc-fee7e8216d24@oktetlabs.ru> 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=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 :)