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 BF103A00C3;
Thu, 23 Jun 2022 09:55:04 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 5E3394069D;
Thu, 23 Jun 2022 09:55:04 +0200 (CEST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
(mail-vi1eur05on2046.outbound.protection.outlook.com [40.107.21.46])
by mails.dpdk.org (Postfix) with ESMTP id 5000C4069C;
Wed, 22 Jun 2022 08:26:09 +0200 (CEST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=B+Qi9PKYwbsTuMSNd4VcM0HHoSVzhI67GI6MAbI8eNBVw3O1AFB0q2xxmVHK3K4scRqQayFa03AiH9DK8YK4AEnKs4bzQvf5yyHAu5zV5cRcELnFPh0ZpYZTxz3bPgO5Vw5vLfa0bF7FZrRP5whjWBoyMSj8b983RLEYWQUb56guu8jXsxrfEpxg4QdaqgWTtRIGo8F5S+o8wYQ5aHt7wUKw+x6nmdRA9HeJaCbt5C7VvtiLZs90JkUiR7V1CJJjlZ5AyU5TJ6E7W4tER8lIYizOVUCCCURJ/aVQrEO44KcrDXuciEbJGxXmhX2ai9Kweqqp5p9LQJku4eP7+JMrKQ==
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=W7Z+1RrW3oQPk1Je5iuKqjqrzlclshNV+ZkYRcSpLyY=;
b=VCkLY+eI8dY640CWTT2rIJdLsXEhsv5jVtb2brKW1yIXY3u0rsFgaHgzzMNEpjZI6l/xcsVQYMOz7rx0uRLclVxqa6T3Vg7wpYWdfSEShmobmpaJugwMS0bEr/FYafH3dlU6U8R4sQcJFEWcNQjNgFqxlcWTctLeqZZBWMzxPjzzc6ItfvMvRaF6TL8LXScDin93lm/Bx6V6um7EIrmVsT3Gw4m+D8ngKbxOawca/ifIrXWbZFpJj2FM1af/fJnYBUt2uGQvgocy/kQEizryeFZNqXnZllZMIds1IwXnk0cwD4fDnUNYQEeC1w9GYA1wc0/i8QGn2BvZIlNVNOCCBQ==
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=W7Z+1RrW3oQPk1Je5iuKqjqrzlclshNV+ZkYRcSpLyY=;
b=K5runXQEC+cQPKMW2MrRvNcRm4bPA958Pbf8oRAh2pFKSajMjIWJMl1KUzOZnb5peCoaWLbJqvvfRm0GvpD3/TqJMzyyiFGJfFrAu+n+E/nu4kd/TjjFDQbpvDfShsuiDt+O16KBALxGao7Q1K1gWBeAAbs6i5ncRtueB842fEM=
Received: from AM8PR07MB7666.eurprd07.prod.outlook.com (2603:10a6:20b:240::23)
by AM6PR07MB6101.eurprd07.prod.outlook.com (2603:10a6:20b:9f::14)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.15; Wed, 22 Jun
2022 06:26:07 +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
06:26:07 +0000
From: Emil Berg <emil.berg@ericsson.com>
To: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
CC: Bruce Richardson <bruce.richardson@intel.com>, Stephen Hemminger
<stephen@networkplumber.org>, "stable@dpdk.org" <stable@dpdk.org>,
"bugzilla@dpdk.org" <bugzilla@dpdk.org>, "hofors@lysator.liu.se"
<hofors@lysator.liu.se>, "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [PATCH] net: fix checksum with unaligned buffer
Thread-Topic: [PATCH] net: fix checksum with unaligned buffer
Thread-Index: AQHYgiaa5HfwvbWOiEyQ5g/wygBtSq1TTuaAgATMtJCAAAQg8IABVuVggAAFVwCAABAOAIAAFBGAgAFa5uA=
Date: Wed, 22 Jun 2022 06:26:07 +0000
Message-ID: <AM8PR07MB766630B5F8D691118E5C6DE298B29@AM8PR07MB7666.eurprd07.prod.outlook.com>
References: <98CBD80474FA8B44BF855DF32C47DC35D87139@smartserver.smartshare.dk>
<20220617084505.62071-1-mb@smartsharesystems.com>
<98CBD80474FA8B44BF855DF32C47DC35D8713A@smartserver.smartshare.dk>
<AM8PR07MB766628919D85FADCE736DD1E98B09@AM8PR07MB7666.eurprd07.prod.outlook.com>
<98CBD80474FA8B44BF855DF32C47DC35D87141@smartserver.smartshare.dk>
<AM8PR07MB7666FECEDEA02E384B5C918998B39@AM8PR07MB7666.eurprd07.prod.outlook.com>
<98CBD80474FA8B44BF855DF32C47DC35D87145@smartserver.smartshare.dk>
<YrF/9njc1dRUrk5v@bricha3-MOBL.ger.corp.intel.com>
<98CBD80474FA8B44BF855DF32C47DC35D87148@smartserver.smartshare.dk>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87148@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: 59c3ec09-d197-4723-8150-08da5418177a
x-ms-traffictypediagnostic: AM6PR07MB6101:EE_
x-microsoft-antispam-prvs: <AM6PR07MB6101642E644ECE6D4B818DD798B29@AM6PR07MB6101.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: t0ZHDXmQTWM9kz6RmptQlR7TqKMCC0LuHyOopOHwXpLY3v6wt7tPpaVvliGpJjPcGPM2Q7v9nU7Bhm6DZGOCIrYPbx+mwY+1k3KCPssdI21EIgtRWl5QGC+SN3fKvSGg3hxFVFoQ7WQFNua1q08pg0vt1/l2zd+A5MpMWCS4ufK3JcjWCwcs1YfGafEnqr68ab4FNMoTncnJv6dUdCfp7PPw21/UReaOuwKaJKpCU/AMels5vKPDrSSUNmSsFLWUXFTv+eqc/Gtc4R+IYY1Wj/hHMrlU+ROYwxWTjBuY2S/sEPrAEJyIhkzFCuI+KmXIyYuwyPwK8LZkXHyM8mc+hg55Z8igbNbgFyuX9fBxvcEOZY7nynz7kx7H2OjgcqqScSgBxoiTmMN/9dkMcLRBJglw75ehU8ncsqN/Q/LTYxjw8YQAhC9QtLdDtY82VuTHt6megMfHib3xV+KY+a/smZFXIX2UfEhf9WJPeTRFj71DxIOi0EqCOxTqZc4PnhxxniSWYiABJ47TkRxaJyWO8rUd1iFE0EGgnVdfQxX+1SZCh3Lu1vrybgug5ca3ySvO4vMA42LP068qLI5CLiVvzK2c64m74QKoJdZCTyZAC7bTMLBgZtQ34Zn0JOFeeWYIt+iZvCm4hzMUtpO/4NzTRqJSKE2vh2u+tBUQxXpVlluozgmq20TSV+ZiI5Y0aMoRiSoliJwjrpLS3KQJs8k7YWraS/o87f3GwR3U4Vi5QtJfq7YUM/Mm2zF9l3snrXrr8csCDcUdseCoHYWf9z/En0m5F61m3TG1+7gRl/F7TzM=
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)(39860400002)(396003)(366004)(376002)(136003)(346002)(66574015)(2906002)(41300700001)(186003)(52536014)(8936002)(44832011)(7696005)(53546011)(33656002)(26005)(83380400001)(478600001)(55016003)(71200400001)(966005)(66446008)(6506007)(9686003)(122000001)(66556008)(86362001)(38100700002)(6916009)(76116006)(66946007)(5660300002)(54906003)(64756008)(66476007)(38070700005)(82960400001)(4326008)(316002)(8676002);
DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?xbzQu94JCB8GQUoilh4AyrfcGPSsw6EwJBwibXHZDPG8dBfFq1dIazDkVN?=
=?iso-8859-1?Q?rn4HFgTk3jBfsx4GsTEqiSGYUIoHbzCQVOF6FaBgthfKELmjckLVU5xUEi?=
=?iso-8859-1?Q?7sVdwvOGcYvbBFrxDpjia9kEQ+l2okCxPu61Cq/2s2SapONAoYX6piUnvq?=
=?iso-8859-1?Q?GimcFI8KvFD+CXCcH1W96iXfQC46dBRZBzFaHgDO/AXwCODXqzczHOhG2B?=
=?iso-8859-1?Q?/awoduBZ/9UcysWLE+QZHPi4JEro1OlG12Sojh3SZsVJQmqQvqDkIsW8np?=
=?iso-8859-1?Q?PmPwh38ZLQHXIJXMEN8KczuWABaVZXPNXwOpyZ7NQmMrxkMwGL4BzfSYyn?=
=?iso-8859-1?Q?iM0I8YRimBDOqv29igLXVTv716flBAtnwX47RNM+3/TVMJLitqiG3gkWo9?=
=?iso-8859-1?Q?ytmkKKQJAApHfTx+pXP3W5TsyG6yzla0WIuAmMDnN1mZ6Ljt476Bdt+jVH?=
=?iso-8859-1?Q?n4eESebp0buqq8H4bIMKeXBVyohAnJN8WD9RK8Q9/aaLCjf1XUk39MTnJi?=
=?iso-8859-1?Q?emQvTy9fU7gFs4LLJVp4vc+ar+MM+kI9O3iG9dxvHVrlJ5pwlPrmhHgfn+?=
=?iso-8859-1?Q?0MujMkj+uUWNgeIu93Hcm0HR59IzBlOsOubo9CTy+jf2RMqY4tVTEhTNHX?=
=?iso-8859-1?Q?AtXFRu71lfUzVAhaGvXOQKAeabb8wVJPNMDUzx2wxKYgL2x8ULZGVtS0Is?=
=?iso-8859-1?Q?wZEDP1dD9PnnWRmxCZvD1FXBwDy+F2o2yp/y0PtzXO09yJOH09G7lQMtN9?=
=?iso-8859-1?Q?V62Gt+s+qFtoNXpF+W6FY4AWDuH2Nb8OYyXViW5xZlDcICUsX9109L7aTm?=
=?iso-8859-1?Q?Ly6p0V4mP6l9GZ3jyf/S7fPM87VrrNCZ/HIC73g+UKUQHdUIED6mJUo38k?=
=?iso-8859-1?Q?+SP+uGzF2ODQoofU3XFv5rMj3Vb/CJSEnqbsFXbI8y2+i6s5IbKGOjAGJL?=
=?iso-8859-1?Q?vWPYU/m9f0l5dKlUgRTgjsMePnokTRA3QFD+vvguHJmTMe0n7afqZzAvPi?=
=?iso-8859-1?Q?OOOVLbrxMho7Pl4QPoBCQTjCu2uFtMT5R9rL65lGSDfjy6Pz9UC0m4dCk/?=
=?iso-8859-1?Q?1WON9pD7pBoNfvzNFzXt3eR9lot8YYTZW4HmjswTtix7lJbTj2/w6+VYxr?=
=?iso-8859-1?Q?wSO9MV6kDnSVbls27sqkL1JVBL/V+YuwQknLcpaITgEj1hjsBkWQuzMEKF?=
=?iso-8859-1?Q?MOg5UcOTus4zK9mBv2kTNNyZeX3tTHKbiGVPo4UCepCtGeYm3GpeEEv9AE?=
=?iso-8859-1?Q?2zEJQ0LRDuI222LXYF05IBWPRf/IEYjOpPBEYdhF28XELalXefV1HfN8yl?=
=?iso-8859-1?Q?YV32TcO8qswEV59NHAuPy/HZrCrZNT0C1S4oLMJzdNOt4XgjSiYMDhNOJS?=
=?iso-8859-1?Q?WdCbsnuu4DIsY+x9ROyhBomVtgwJYj/bzZhbw4jzMY+qvzJEIh69K5QfjV?=
=?iso-8859-1?Q?NJVfhE3/qi4QkcmDFtThgxlOXaat3HQXjyyqLVqqEPniUyr/qd+HL+3lGb?=
=?iso-8859-1?Q?Uv5gWeVCIxm2SgVrbFZLRautbw8o6g0AWh4tYYIxKvx9vKEsFudpvbZbAR?=
=?iso-8859-1?Q?aEu3lcT53IXXWuFtuhGNYfYvAFxlnkRIZVR+m76wKOUClnxVA9YcAq38T0?=
=?iso-8859-1?Q?2+h0zl2BUNTxOjo1snqdZmZNIHEUmh9nGw?=
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: 59c3ec09-d197-4723-8150-08da5418177a
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2022 06:26:07.6043 (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: q45zOIgH+vd0S9u2C/45IPGN4LM61rVE8yoUHAC7zpKdige41ev1wwP2RrJHb8Dd6akySrHfcjhbQZFFLdTfSA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6101
X-Mailman-Approved-At: Thu, 23 Jun 2022 09:55:03 +0200
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
> -----Original Message-----
> From: Morten Br=F8rup <mb@smartsharesystems.com>
> Sent: den 21 juni 2022 11:35
> To: Emil Berg <emil.berg@ericsson.com>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Stephen Hemminger
> <stephen@networkplumber.org>; 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: 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 <mb@smartsharesystems.com>
> > > > > 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 <mb@smartsharesystems.com>
> > > > > > > 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 <mb@smartsharesystems.com>
> > > > > > > > ---
> > > > > > > > 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
> >
>=20
> @Emil, can you please describe or refer to which tunneling protocol you a=
re
> using, where the nested packet can be unaligned?
>=20
> 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.
>=20
> If possible, please provide more details about the tunneling protocol and
> nested packets... E.g. do the nested packets also contain Layer 2 (Ethern=
et,
> VLAN, etc.) headers, or only Layer 3 (IP) or Layer 4 (TCP, UDP, etc.)? An=
d how
> about ARP packets and Layer 2 control protocol packets (STP, LACP, etc.)?
>=20
Well, if you append or adjust an odd number of bytes (e.g. a PDCP header) f=
rom a previously aligned payload the entire packet will then be unaligned.
> > >
> > > [1]
> > https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273af-4544=
4
> > 5555731-713e91ae28ea4a95&q=3D1&e=3D91f8f355-4366-43bd-ac93-
> 4c2f375f8d25&u=3D
> >
> http%3A%2F%2Fgit.dpdk.org%2Fdpdk%2Fcommit%2Flib%2Flibrte_net%2Frt
> e_eth
> > er.h%3Fid%3Dda5350ef2
> > 9afd35c1adabe76f60832f3092269ad
> > >
> > > @Emil, we should wait for a conclusion about the alignment invariant
> > before we proceed.
> > >
> > > If there is no such invariant, my patch is wrong, and we need to
> > provide a v2 of the patch, which will then fit your use case.
> > > If there is such an invariant, my patch is correct, and another
> > function must be added for your use case.
> > >