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 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 To: =?iso-8859-1?Q?Morten_Br=F8rup?= CC: Bruce Richardson , 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/wygBtSq1TTuaAgATMtJCAAAQg8IABVuVggAAFVwCAABAOAIAAFBGAgAFa5uA= Date: Wed, 22 Jun 2022 06:26:07 +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> 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > -----Original Message----- > From: Morten Br=F8rup > Sent: den 21 juni 2022 11:35 > To: Emil Berg > Cc: Bruce Richardson ; 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: 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 > > >=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. > > >