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 F1C54A00C3 for ; Thu, 23 Jun 2022 09:55:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9CD7742823; Thu, 23 Jun 2022 09:55:28 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30081.outbound.protection.outlook.com [40.107.3.81]) by mails.dpdk.org (Postfix) with ESMTP id 4A08B4069F; Wed, 22 Jun 2022 14:25:13 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dN31DkkCUtW2crFySaSfZvKR4IfrhWHelnFnOULjCXmp8NJ/7Vj9/3cHo5QLFZ2c0nhvSf8p0quxeHrVGZtrf+IOlIxWakdZixi8G/twQEsT9+w5T2R6WqPSW2/efPCH0GsT7yFguYHgJu8b+GZwsC7D/8WE5DfQmVtZD9/swbtx3/D1wR2BXuurd3S91kbkHmlS/D+MeiZ9dNWFcsBjZiuGdSk+cxnNtDhz3Rwb8DHvgRFjfxHm3iALRBu2eS6OmTq5yYXnolA6fDt5XvKyvyDMYRl7zldAJ6nFunzYFrEMkMH00R5PASOPnIFXsR94iQchUVcy2ILhFpjsL5qfgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=W6UIpcXGQk5N2AwzKYd2P56neOS2bq7/medWPpKsiRI=; b=m++QxGaUBdVP7nL31QV98MOD3DxUg9kakyEUJj65SGD2ljVxQhQ6BQG2XfLy2olhcAcdnBprF/AckISrDZslL5Ly8ebSzSSrtIOqeG+JI8I/GTNgmdmlsl2avKpUcO9nZ9vvPKGegQBCp0YvQ35k4XqVIl1ScwV+OwKj7a0g9I0iJGXlIbkQ0kfXiD5yxkl30Tu3dJvZV9T200rYgZiAzz8A24EYgime7sA+BnJUiIYaNf+gn+/jeHij5anhnB2AeamDl/zQNRDsu/XCWGG3kxOsUB9ywMo6nsCsG+IjotRetfaBXveg8ikLK1+sYt39YDU7J6AlcHny3WvIbL/D5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W6UIpcXGQk5N2AwzKYd2P56neOS2bq7/medWPpKsiRI=; b=lAY90n7haT1rNqWWYDeJu56Hp0rjw0Uu76yqLEB4EPSirL5n2sWQRdawQ2Ase4O4OIG97FJOZ3v+Pk6Ec3K/oIBYC/jby8FxhMVKoOoefYq9gEyI9cJk74e+R5GwdMdVUoG6CDhozTkIs9jnQn4Cnzf8r8iq1RvEzBMPnpObHq8= Received: from AM8PR07MB7666.eurprd07.prod.outlook.com (2603:10a6:20b:240::23) by AM6PR07MB5958.eurprd07.prod.outlook.com (2603:10a6:20b:8e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.13; Wed, 22 Jun 2022 12:25:11 +0000 Received: from AM8PR07MB7666.eurprd07.prod.outlook.com ([fe80::188:e139:774e:cea1]) by AM8PR07MB7666.eurprd07.prod.outlook.com ([fe80::188:e139:774e:cea1%7]) with mapi id 15.20.5373.015; Wed, 22 Jun 2022 12:25:11 +0000 From: Emil Berg To: =?iso-8859-1?Q?Morten_Br=F8rup?= , Bruce Richardson CC: Stephen Hemminger , "stable@dpdk.org" , "bugzilla@dpdk.org" , "hofors@lysator.liu.se" , "olivier.matz@6wind.com" , "dev@dpdk.org" Subject: RE: [PATCH] net: fix checksum with unaligned buffer Thread-Topic: [PATCH] net: fix checksum with unaligned buffer Thread-Index: AQHYgiaa5HfwvbWOiEyQ5g/wygBtSq1TTuaAgATMtJCAAAQg8IABVuVggAAFVwCAABAOAIAAFBGAgAFa5uCAADK3AIAAI7mAgAAOwgA= Date: Wed, 22 Jun 2022 12:25:11 +0000 Message-ID: References: <98CBD80474FA8B44BF855DF32C47DC35D87139@smartserver.smartshare.dk> <20220617084505.62071-1-mb@smartsharesystems.com> <98CBD80474FA8B44BF855DF32C47DC35D8713A@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87141@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87145@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87148@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87152@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87152@smartserver.smartshare.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2bf769e-e58a-4e9b-0e05-08da544a40ab x-ms-traffictypediagnostic: AM6PR07MB5958:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZqcayKRv22ZhVR7pIwzZPBtTlMOIgmVS0iJ5WG3xIvvJfmBOCxFEmDzelO1j9evNIcd+GS7bJjmUd4d/9BnKbi3j+YGrhhjVMorgfZBrjUmVAiVN4Cp0iSQZwoKeJHs4r2D7DAErEk5NwSVohGvdaIlpVuapiA0H7xdH0Yg4tG/PNw3XgUOuO/9busFyqUz/QCbF+ycFsZUERNyPhhbeJBu1NTP6UA2niaTcGubYYu9PE1fIOAp7W1ZmyZRT8IqOXaxqleWB6x+5ZhEfpjmO6B4dxWsQo9CC4NCKtbg3BNFCBiA0bCbARevkAsxdb4D9eKld4yi8dyPMvuNcQkqKHSHEVEkkl37NYpkSZdtAnoFVSGomURb9H8VVCqVsTdtL3cMqSa4yZvOzRrL19QIgE/McHow9fyyCmWQGytBnbVeCw3IH4PMonpwu8G/7p9PrNDe699up+o8RV2+SjX10u+gQNd2IOMnGO2drJsqVAn6xeWaK/ylPaZiuT8kECGjtiTUgEeZHaNb0nIESjAYwzDagqIs/OKiLh9BfflTuPWMLmmSKzVqnKQ214NH4gMPa4FSH/AZW0Lrt04ZEN60cBHzfnsq406bRtI3WVQM7LZMWT8HY1oZT/2PqOlE19+C5OAS3scOSLuETDTACIS1u0JdmRR8pjhDRpmh4G+8167nAZOLnFnnp5vZC2qJl8Wlhg+CESJBakAt8bD3TdjF5sz2s73oUZnt03aLFMpp4hryQb0zSAA64xuXQ3GomMec/YMmFndOibmMMBmISYje05HWjWyZfc0Qf71w6kZlyRHU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB7666.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(366004)(396003)(136003)(376002)(39860400002)(346002)(38100700002)(41300700001)(8936002)(53546011)(66946007)(966005)(55016003)(38070700005)(66556008)(82960400001)(7696005)(30864003)(66476007)(6506007)(478600001)(52536014)(110136005)(33656002)(122000001)(71200400001)(76116006)(9686003)(2906002)(186003)(44832011)(83380400001)(86362001)(26005)(66574015)(64756008)(316002)(4326008)(54906003)(66446008)(5660300002)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?8cf5ndiGmA2pIwUWebsx8uGcTQ796GxOJ5GaIEPGFNsUvvrBVUbrUuqM/H?= =?iso-8859-1?Q?LPZlMTIzAY9s+xU+ijXuHOPqBK9wucTWm1DKApbKBWoCLM/n74LtA3vwEa?= =?iso-8859-1?Q?oF5whyv3Luvdk+oatn6TGs364GEIYcYxAv5MDFOkEtQoY7BbEp1EGdFzsy?= =?iso-8859-1?Q?+dRfsGjbUKmRaTW23r6hhzJUVEmARlhtak2SowwqcoHxyY0J99rYQJu/pq?= =?iso-8859-1?Q?Oey3JspobYTIZIjZRRJi3TR+PrSYpVk4AJiHFX+1mskCJjYWpzYsMNzccy?= =?iso-8859-1?Q?gtf9dy4zX691Tz8RmBfGXiJjF8JG406Kbmc3GyQskjdUihLGBnrqxIy4Ve?= =?iso-8859-1?Q?5M4Kmfg54/6ShVPAQqHakqvjohNq8Hq4swcZkxpCVK5C14ZKX+Bfct+giJ?= =?iso-8859-1?Q?XS5EkUDQmnl7JfX0TnPU6TtqpNDqO8ItWkfMXvb4VtI9KhRUWnS/W4QuXx?= =?iso-8859-1?Q?3syh9Fa9KxLTJabmhW2atOGoL7Iw9xTvSLzbUvkzEvAIovx3T/emCx7HM1?= =?iso-8859-1?Q?Mwci311OKYGt94epDK2/NO8/zWB4aIKjfD4ZpG4HsKtmp44Lzz8TyvpWjO?= =?iso-8859-1?Q?Y2kVTB18EcK2hKm9oSo7X91I5+2YRNAKfcQq3DudGMm2vqCvsOnQQZ83x/?= =?iso-8859-1?Q?Y7Ulsdj+nPP1+vgibhDw0yjkKxw7ILBYArNifGDiUQP1M3HURHO310rvk+?= =?iso-8859-1?Q?HWL7lTouTteIwwqX37QjUXRaFQq6bbQC9q3cWpYv0FR/a3CqV/zHTATM8T?= =?iso-8859-1?Q?vaynVO3Be9iCdbpOlf5Jigqcz1i4ByT65bYBUSYwbrZdYgc8iRJE28uWXg?= =?iso-8859-1?Q?bdOGZJC5XUbRYoxWcr3ZeLjdjngUSL7qybQhGv0SgbK+Db29S/hBVbBCXD?= =?iso-8859-1?Q?2z6YRI6lvENHh9dE3qaq3GNhDcVxAIGIQZhYIAd2kYceqTiIs5zKz0ypOY?= =?iso-8859-1?Q?dUX2A3vwo0IQiYGglPi5klljAye2EM1+0nM/bPzncJ0hekHg5+3DCrtZwa?= =?iso-8859-1?Q?r+yODYTN5aEkxsc8E5xY9AG2L7s7jVG1jo7NhToT4eEywWzJBG7fb/db9p?= =?iso-8859-1?Q?KEE6/smsMN9EFWwTyml8D+Fov9DoGxhcTuOn3t1z9Dcu4hluRbyKvjBUgA?= =?iso-8859-1?Q?BO50YiQ2LrMfbvhbSieUCVsTXuS0SdeW4QOt37y1+D0GQnw6FtAcrbFqQA?= =?iso-8859-1?Q?zdgEKsC5hXMrXH67shd7PabJnfhwG/JEeWumD6lx2mfr0IovemxJBHkQ5f?= =?iso-8859-1?Q?ERdzDpgJmkys6+QrjCF9DRD+awrMfkYx1SDnxOkuXd07IbTOIrJ7YE29bA?= =?iso-8859-1?Q?H7yorEi+ljHH8S5f4heVWtoWZWirWXmgyJPK4rPIjvlaBPIWQFMpUgxr8w?= =?iso-8859-1?Q?Uk5jUgu84HlgHeV0A+mhMqyGghoMycHZ5bv/sr9Ep5f26Eq+G56Bwmu5YP?= =?iso-8859-1?Q?424wBI5bXTafMcSaF2cy5cVjAlKODtLO2g2GsT7X+RB7E7CjbKWAJwGyjW?= =?iso-8859-1?Q?QBNH8NEkShFysKReRXjdHUR6p+YKT8LZZ6XkMr4ffJCN5T8VUjX2FyY1Gz?= =?iso-8859-1?Q?r8KgHQzUe2WypWfnfqfO05N6EU4oiXceqx414H5DhsmX/JbQgjFKZ2Jzya?= =?iso-8859-1?Q?d9B5SHLrRU3JSkd48JVr6nAEYW9U5UUyK2?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7666.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c2bf769e-e58a-4e9b-0e05-08da544a40ab X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2022 12:25:11.4986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hLDf7VSJumVTY3j46sq+7+oofOK14Ej1e+G9lHYUKp2BrUu1KHC7U2AH9cIrQSAZGmBPKFsOKVI7NBZ+Ps0Vkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5958 X-Mailman-Approved-At: Thu, 23 Jun 2022 09:55:26 +0200 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 > -----Original Message----- > From: Morten Br=F8rup > Sent: den 22 juni 2022 13:26 > To: Bruce Richardson ; Emil Berg > > Cc: Stephen Hemminger ; > stable@dpdk.org; bugzilla@dpdk.org; hofors@lysator.liu.se; > olivier.matz@6wind.com; dev@dpdk.org > Subject: RE: [PATCH] net: fix checksum with unaligned buffer >=20 > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > Sent: Wednesday, 22 June 2022 11.18 > > > > On Wed, Jun 22, 2022 at 06:26:07AM +0000, Emil Berg wrote: > > > > > > > From: Morten Br=F8rup > > > > Sent: den 21 juni 2022 11:35 > > > > > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > > Sent: Tuesday, 21 June 2022 10.23 > > > > > > > > > > On Tue, Jun 21, 2022 at 10:05:15AM +0200, Morten Br=F8rup wrote: > > > > > > +TO: @Bruce and @Stephen: You signed off on the 16 bit > > alignment > > > > > requirement. We need background info on this. > > > > > > > > > > > > > From: Emil Berg [mailto:emil.berg@ericsson.com] > > > > > > > Sent: Tuesday, 21 June 2022 09.17 > > > > > > > > > > > > > > > From: Morten Br=F8rup > > > > > > > > Sent: den 20 juni 2022 12:58 > > > > > > > > > > > > > > > > > From: Emil Berg [mailto:emil.berg@ericsson.com] > > > > > > > > > Sent: Monday, 20 June 2022 12.38 > > > > > > > > > > > > > > > > > > > From: Morten Br=F8rup > > > > > > > > > > Sent: den 17 juni 2022 11:07 > > > > > > > > > > > > > > > > > > > > > From: Morten Br=F8rup > > > > > > > > > > > [mailto:mb@smartsharesystems.com] > > > > > > > > > > > Sent: Friday, 17 June 2022 10.45 > > > > > > > > > > > > > > > > > > > > > > With this patch, the checksum can be calculated on > > > > > > > > > > > an > > > > > unligned > > > > > > > > > > > part > > > > > > > > > of > > > > > > > > > > > a packet buffer. > > > > > > > > > > > I.e. the buf parameter is no longer required to be > > > > > > > > > > > 16 > > bit > > > > > > > aligned. > > > > > > > > > > > > > > > > > > > > > > The DPDK invariant that packet buffers must be 16 > > > > > > > > > > > bit > > > > > aligned > > > > > > > > > remains > > > > > > > > > > > unchanged. > > > > > > > > > > > This invariant also defines how to calculate the 16 > > bit > > > > > > > checksum > > > > > > > > > > > on > > > > > > > > > an > > > > > > > > > > > unaligned part of a packet buffer. > > > > > > > > > > > > > > > > > > > > > > Bugzilla ID: 1035 > > > > > > > > > > > Cc: stable@dpdk.org > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Morten Br=F8rup > > > > > > > > > > > > > --- > > > > > > > > > > > lib/net/rte_ip.h | 17 +++++++++++++++-- > > > > > > > > > > > 1 file changed, 15 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h > > index > > > > > > > > > > > b502481670..8e301d9c26 100644 > > > > > > > > > > > --- a/lib/net/rte_ip.h > > > > > > > > > > > +++ b/lib/net/rte_ip.h > > > > > > > > > > > @@ -162,9 +162,22 @@ __rte_raw_cksum(const void > > > > > > > > > > > *buf, > > > > > size_t > > > > > > > len, > > > > > > > > > > > uint32_t sum) { > > > > > > > > > > > /* extend strict-aliasing rules */ > > > > > > > > > > > typedef uint16_t > __attribute__((__may_alias__)) > > > > > u16_p; > > > > > > > > > > > - const u16_p *u16_buf =3D (const u16_p *)buf; > > > > > > > > > > > - const u16_p *end =3D u16_buf + len / > > sizeof(*u16_buf); > > > > > > > > > > > + const u16_p *u16_buf; > > > > > > > > > > > + const u16_p *end; > > > > > > > > > > > + > > > > > > > > > > > + /* if buffer is unaligned, keeping it byte > > order > > > > > > > independent */ > > > > > > > > > > > + if (unlikely((uintptr_t)buf & 1)) { > > > > > > > > > > > + uint16_t first =3D 0; > > > > > > > > > > > + if (unlikely(len =3D=3D 0)) > > > > > > > > > > > + return 0; > > > > > > > > > > > + ((unsigned char *)&first)[1] =3D > *(const > > unsigned > > > > > > > > > > char *)buf; > > > > > > > > > > > + sum +=3D first; > > > > > > > > > > > + buf =3D (const void *)((uintptr_t)buf > + 1); > > > > > > > > > > > + len--; > > > > > > > > > > > + } > > > > > > > > > > > > > > > > > > > > > > + u16_buf =3D (const u16_p *)buf; > > > > > > > > > > > + end =3D u16_buf + len / sizeof(*u16_buf); > > > > > > > > > > > for (; u16_buf !=3D end; ++u16_buf) > > > > > > > > > > > sum +=3D *u16_buf; > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > 2.17.1 > > > > > > > > > > > > > > > > > > > > @Emil, can you please test this patch with an > > > > > > > > > > unaligned > > > > > buffer on > > > > > > > > > your > > > > > > > > > > application to confirm that it produces the expected > > result. > > > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > I tested the patch. It doesn't seem to produce the same > > > > > results. I > > > > > > > > > think the problem is that it always starts summing from > > an > > > > > > > > > even address, the sum should always start from the first > > byte > > > > > according > > > > > > > to > > > > > > > > > the checksum specification. Can I instead propose > > something > > > > > Mattias > > > > > > > > > R=F6nnblom sent me? > > > > > > > > > > > > > > > > I assume that it produces the same result when the "buf" > > > > > parameter is > > > > > > > > aligned? > > > > > > > > > > > > > > > > And when the "buf" parameter is unaligned, I don't expect > > it to > > > > > > > produce the > > > > > > > > same results as the simple algorithm! > > > > > > > > > > > > > > > > This was the whole point of the patch: I expect the > > > > > > > > overall > > > > > packet > > > > > > > buffer to > > > > > > > > be 16 bit aligned, and the checksum to be a partial > > checksum of > > > > > such > > > > > > > a 16 bit > > > > > > > > aligned packet buffer. When calling this function, I > > > > > > > > assume > > that > > > > > the > > > > > > > "buf" and > > > > > > > > "len" parameters point to a part of such a packet buffer. > > If > > > > > these > > > > > > > > expectations are correct, the simple algorithm will > > > > > > > > produce > > > > > incorrect > > > > > > > results > > > > > > > > when "buf" is unaligned. > > > > > > > > > > > > > > > > I was asking you to test if the checksum on the packet is > > > > > > > > correct > > > > > > > when your > > > > > > > > application modifies an unaligned part of the packet and > > uses > > > > > this > > > > > > > function to > > > > > > > > update the checksum. > > > > > > > > > > > > > > > > > > > > > > Now I understand your use case. Your use case seems to be > > about > > > > > partial > > > > > > > checksums, of which some partial checksums may start on > > unaligned > > > > > > > addresses in an otherwise aligned packet. > > > > > > > > > > > > > > Our use case is about calculating the full checksum on a > > nested > > > > > packet. > > > > > > > That nested packet may start on unaligned addresses. > > > > > > > > > > > > > > The difference is basically if we want to sum over aligned > > > > > addresses or > > > > > > > not, handling the heading and trailing bytes appropriately. > > > > > > > > > > > > > > Your method does not work in our case since we want to treat > > the > > > > > first > > > > > > > two bytes as the first word in our case. But I do understand > > that > > > > > both > > > > > > > methods are useful. > > > > > > > > > > > > Yes, that certainly are two different use cases, requiring two > > > > > different ways of calculating the 16 bit checksum. > > > > > > > > > > > > > > > > > > > > Note that your method breaks the API. Previously (assuming > > > > > > > no > > > > > crashing > > > > > > > due to low optimization levels, more accepting hardware, or > > > > > > > a > > > > > different > > > > > > > compiler (version)) the current method would calculate the > > > > > > > checksum assuming the first two bytes is the first word. > > > > > > > > > > > > > > > > > > > Depending on the point of view, my patch either fixes a bug > > (where > > > > > the checksum was calculated incorrectly when the buf pointer was > > > > > unaligned) or breaks the API (by calculating the differently > > > > > when > > the > > > > > buffer is unaligned). > > > > > > > > > > > > I cannot say with certainty which one is correct, but perhaps > > some > > > > > > of > > > > > the people with a deeper DPDK track record can... > > > > > > > > > > > > @Bruce and @Stephen, in 2019 you signed off on a patch [1] > > > > > introducing a 16 bit alignment requirement to the Ethernet > > address > > > > > structure. > > > > > > > > > > > > It is my understanding that DPDK has an invariant requiring > > packets > > > > > to be 16 bit aligned, which that patch supports. Is this > > invariant > > > > > documented anywhere, or am I completely wrong? If I'm wrong, > > > > > then > > the > > > > > alignment requirement introduced in that patch needs to be > > removed, as > > > > > well as any similar alignment requirements elsewhere in DPDK. > > > > > > > > > > I don't believe it is explicitly documented as a global > > invariant, but > > > > > I think it should be unless there is a definite case where we > > need to > > > > > allow packets to be completely unaligned. Across all packet > > headers we > > > > > looked at, there was no tunneling protocol where the resulting > > packet > > > > > was left unaligned. > > > > > > > > > > That said, if there are real use cases where we need to allow > > packets > > > > > to start at an unaligned address, then I agree with you that we > > need > > > > > to roll back the patch and work to ensure everything works with > > > > > unaligned addresses. > > > > > > > > > > /Bruce > > > > > > > > > > > > > @Emil, can you please describe or refer to which tunneling > > > > protocol > > you are > > > > using, where the nested packet can be unaligned? > > > > > > > > I am asking to determine if your use case is exotic (maybe some > > Ericsson > > > > proprietary protocol), or more generic (rooted in some standard > > protocol). > > > > This information affects the DPDK community's opinion about how it > > should > > > > be supported by DPDK. > > > > > > > > If possible, please provide more details about the tunneling > > protocol and > > > > nested packets... E.g. do the nested packets also contain Layer 2 > > (Ethernet, > > > > VLAN, etc.) headers, or only Layer 3 (IP) or Layer 4 (TCP, UDP, > > etc.)? And how > > > > about ARP packets and Layer 2 control protocol packets (STP, LACP, > > etc.)? > > > > > > > > > > Well, if you append or adjust an odd number of bytes (e.g. a PDCP > > header) from a previously aligned payload the entire packet will then > > be unaligned. > > > > > > > If PDCP headers can leave the rest of the packet field unaligned, then > > we had better remove the alignment restrictions through all of DPDK. > > > > /Bruce >=20 > Re-reading the details regarding unaligned pointers in C11, as posted by = Emil > in Bugzilla [2], I interpret it as follows: Any 16 bit or wider pointer t= ype a must > point to data aligned with that type, i.e. a pointer of the type "uint16_= t *" > must point to 16 bit aligned data, and a pointer of the type "uint64_t *"= must > point to 64 bit aligned data. Please, someone tell me I got this wrong, a= nd > wake me up from my nightmare! >=20 > Updating DPDK's packet structures to fully support this C11 limitation wi= th > unaligned access would be a nightmare, as we would need to use byte array= s > for all structure fields. Functions would also be unable to use other poi= nter > types than "void *" and "char *", which seems to be the actual problem in > the __rte_raw_cksum() function. I guess that it also would prevent the > compiler from auto-vectorizing the functions. >=20 > I am usually a big proponent of academically correct solutions, but such = a > change would be too wide ranging, so I would like to narrow it down to th= e > actual use case, and perhaps extrapolate a bit from there. >=20 > @Emil: Do you only need to calculate the checksum of the (potentially > unaligned) embedded packet? Or do you also need to use other DPDK > functions with the embedded packet, potentially accessing it at an unalig= ned > address? >=20 > I'm trying to determine the scope of this C11 pointer alignment limitatio= n for > your use case, i.e. whether or not other DPDK functions need to be update= d > to support unaligned packet access too. >=20 > [2] https://protect2.fireeye.com/v1/url?k=3D31323334-501cfaf3-313273af- > 454445554331-2ffe58e5caaeb74e&q=3D1&e=3D3f0544d3-8a71-4676-b4f9- > 27e0952f7de0&u=3Dhttps%3A%2F%2Fbugs.dpdk.org%2Fshow_bug.cgi%3Fid% > 3D1035 That's my interpretation of the standard as well; For example an uint16_t* = must be on even addresses. If not it is undefined behavior. I think this is= a bigger problem on ARM for example. Without being that invested in dpdk, adding unaligned support for everythin= g seems like a steep step, but I'm not sure what it entails in practice. We are actually only interested in the checksumming.