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 5EAD845B61; Thu, 17 Oct 2024 21:34:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F157D40265; Thu, 17 Oct 2024 21:34:58 +0200 (CEST) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by mails.dpdk.org (Postfix) with ESMTP id 9249A4025F for ; Thu, 17 Oct 2024 21:34:57 +0200 (CEST) Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-71e983487a1so631541b3a.2 for ; Thu, 17 Oct 2024 12:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1729193697; x=1729798497; 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=R+LwMuvxdLO8V0pMrM/GHKcl5d/5bXJU2pMAU1gACTs=; b=LnZeJy/iyyFjc+GiJq7fGDwg2K/KqnGCLhzM6jWyolYhHSMhtfXYpVhiCXuvO255F4 IhEC75UBBIjq60VTHffYuJxuSKRd0z4z74VBggghlukcnNijUBIqA5uNRNCd7heajCb3 DIgqRz4pQvdLE6OwTATZM/6KDWh4t5/uu9hTbNauttPZH9MYIpqPDAEYxtCduU/auyla yQBRirbmuOXyACBVG6pjOZ7kM7egqch73YEB85atRQbG+q6Il/EW8BPCcBYJj0aPYxp3 Vdho2U8bun3l13DJR14sC1rKWUmLuXxc3BBqL/BbWZ5tPnvxWg2UD4MZpACCnyB6AHyR qvGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729193697; x=1729798497; 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=R+LwMuvxdLO8V0pMrM/GHKcl5d/5bXJU2pMAU1gACTs=; b=Qts4b4UIz3cgvw2PxDU1K0YAViRUXk7FtORN54AlJ+ibJRn0w6I7EGf0f2tBciEAEk 0URs97n+a8e51Aq7UUAXrFiFpIcHc6Pq8Ko72kHIAVex5DfgMEBJkOz9YgAKQ+UE26iW oAnUS78x33+ds8x08dFKIRpn8AMAeugjAdw4BDE8XakxSg9Vxfyi/JoWLpRlDpSrESLX g64riRsPZ4zDyFZZYNtMUS4NvoPioVKwyNQILKXFRqyHlw3mif5MsEW9UbBvDJeR7+3D axOa2dxQiQvzWJkDrct7k9B5Sp/rL8A47dbI5PrrXnvmhphN07Ut1l3chTi8FBaBzEW+ xZ1A== X-Forwarded-Encrypted: i=1; AJvYcCVZzTKieJ6y57vyuWFPFPIXJxCDLpk8XFnzyPMCjbgXAQculmBaXGbWZ21AqfF2d77HNLA=@dpdk.org X-Gm-Message-State: AOJu0YxIagENdH47LUBpf64qb+MdV54uLCIZP6P6YYOmL3SDpIJcY3Zd WNpwtrAhxpe+YdQFi0llVCBwb4UoBtQhmdjIkQwAoK4ei/xyoaxLt1h/eGGEJNU= X-Google-Smtp-Source: AGHT+IH10pmUPVLJTJux3GzFz0/ccxn8nhFEyYTHllMCuZBJqwgk6VOuuiJtrhoSfdBHURT7QYXB/Q== X-Received: by 2002:a05:6a00:3d16:b0:71e:7c25:8217 with SMTP id d2e1a72fcca58-71ea3338e0amr69466b3a.25.1729193696700; Thu, 17 Oct 2024 12:34:56 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71ea3459365sm13617b3a.150.2024.10.17.12.34.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Oct 2024 12:34:56 -0700 (PDT) Date: Thu, 17 Oct 2024 12:34:54 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , , Jerin Jacob , Aman Singh , Konstantin Ananyev Subject: Re: [PATCH 5/6] net: add smaller IPv4 cksum function for simple cases Message-ID: <20241017123454.302a7203@hermes.local> In-Reply-To: References: <20241017142214.1669370-1-bruce.richardson@intel.com> <20241017142214.1669370-6-bruce.richardson@intel.com> <98CBD80474FA8B44BF855DF32C47DC35E9F7F3@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 17 Oct 2024 20:03:13 +0100 Bruce Richardson wrote: > On Thu, Oct 17, 2024 at 07:15:10PM +0200, Morten Br=C3=B8rup wrote: > > > +/** > > > + * Process the IPv4 checksum of an IPv4 header without any extension= s. > > > + * > > > + * The checksum field does NOT have to be set by the caller, the fie= ld > > > + * is skipped by the calculation. > > > + * > > > + * @param ipv4_hdr > > > + * The pointer to the contiguous IPv4 header. > > > + * @return > > > + * The complemented checksum to set in the IP packet. > > > + */ > > > +__rte_experimental > > > +static inline uint16_t > > > +rte_ipv4_cksum_simple(const struct rte_ipv4_hdr *ipv4_hdr) > > > +{ > > > + const uint16_t *v16_h; > > > + uint32_t ip_cksum; > > > + > > > + /* > > > + * Compute the sum of successive 16-bit words of the IPv4 header, > > > + * skipping the checksum field of the header. > > > + */ > > > + v16_h =3D (const unaligned_uint16_t *)&ipv4_hdr->version_ihl; > > > + ip_cksum =3D v16_h[0] + v16_h[1] + v16_h[2] + v16_h[3] + > > > + v16_h[4] + v16_h[6] + v16_h[7] + v16_h[8] + v16_h[9]; > > > + > > > + /* reduce 32 bit checksum to 16 bits and complement it */ > > > + ip_cksum =3D (ip_cksum & 0xffff) + (ip_cksum >> 16); > > > + ip_cksum =3D (ip_cksum & 0xffff) + (ip_cksum >> 16); > > > + ip_cksum =3D (~ip_cksum) & 0x0000FFFF; > > > + return (ip_cksum =3D=3D 0) ? 0xFFFF : (uint16_t) ip_cksum; =20 > >=20 > > The zero exception does not apply to the checksum stored in the IP head= er, only to the checksum in the UDP header. > > =20 >=20 > I was wondering about that, because I didn't see it mentioned anywhere in > the RFCs I consulted, but on the other hand all the implementations in the > code seemed to have the check for zero. >=20 > > > +} =20 > >=20 > > Besides that, for the series, =20 >=20 > So, just to confirm, the zero check at the end of the new ip_cksum_simple > function should be removed and we always return the computed value > directly? Depends on usage. - if the computed value is zero, then 0xffff should be placed in the IP header. - often code use ip checksum code to see if incoming checksum is good. in that case zero means the checksum is valid.