From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <users-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 5308A4567F
for <public@inbox.dpdk.org>; Mon, 22 Jul 2024 11:19:24 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id ED2B94333E;
Mon, 22 Jul 2024 11:19:18 +0200 (CEST)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
(mail-dm6nam10on2066.outbound.protection.outlook.com [40.107.93.66])
by mails.dpdk.org (Postfix) with ESMTP id 32CC442F45
for <users@dpdk.org>; Mon, 22 Jul 2024 11:02:16 +0200 (CEST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=J+qElH8yMQm6sQmsVZPSP6kH4i0bCNNtH66LPmXeVN74qGuAdc5up6OE6AvsovYQe+Y6241EibKtigPnPPSb+alMdfN9H1lfYqjMz/92Hd2LPw/Viol0SR2US0hqOw9XUzHychIN/dilnyrkfAEH4jd1P0HtCZ4xBcEuugPmFalX7b7R1ZgDoHf8DFLSEFgeEDRT6PXViIoO6QDP4YamqZmMnvkiK98jxIo7rPvNoN3Ya9/cx8GekjMGB/QahFTGbpkFkxq6mORzQE7bJslMOjpa7+L0gVmTPbhmgLzWeTu/A+gJs+d+UInc8HfQtUSe8iirvp2yV1CbRr3v+CTpXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
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=fdLR8uRc4pbJ+DwwyWECbs7ANdyqnh4XVy+CayNWlOo=;
b=DHz2TkykpwxozL14udiMjJCLvCOHLFFhcwNnvpqNyW5eOMW+KnrMHoM+RkSnKMOsuSpDe+SfNr1hLH5y+rF1MuRtdmJ+pnHLUqyTokyN8N8eOeK2oOSjAp8VwYsvh73sxOAD3NDxbrdUJjeVGLzGCRzzWywOYgzfwV1xYIZsYeSf4B3h0eyD2hYtyobA/7uC2DhJvdYt2eaq+RpfBlfnj1AcxgHXLm9BlUjRgpGMSCp0bOuHe7SUjdupgaF0KDEFQQyPLSAm5AUob5MNhvm5lZp8wKngDTBA16LcosxbuwEyWG1HI3IaomQZT3ZdtCyMc+xzpRodWXP/uDP3qf9ymA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=fdLR8uRc4pbJ+DwwyWECbs7ANdyqnh4XVy+CayNWlOo=;
b=ttlGUh/q69M/W4vfBMtSth+qoVBDG95EnIRd3RkXk1Wt8jzVxeBbdFp3AVuiu7aaC5z/iUVIrv0n5yrrMPdRO/29nWuDu67N08APi4LMvsfm31lgkaf0rmu1HX5LMylcr1bwFnybIQ9xEjwAZ5dDCv1sykh5+CvAMpG8GFkFnAMCf+7+ppust2zjT0FwouoRdUvhYs/h/RNY0pwJJXKwAmlQ+vraPy7c9W6qts/REw7585zbHmofEtmGZR+hrKyprL+K3wxXOknsJXGIcSNtZDM3vyO+M+/lSxuMeGwFnsTvBduQ63ZusxnQRowR00ztz9Uu2XIP8E1dh3ndwZ2Fiw==
Received: from MN0PR12MB6056.namprd12.prod.outlook.com (2603:10b6:208:3cc::12)
by DS0PR12MB7656.namprd12.prod.outlook.com (2603:10b6:8:11f::7) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.14; Mon, 22 Jul
2024 09:02:11 +0000
Received: from MN0PR12MB6056.namprd12.prod.outlook.com
([fe80::4b75:36f4:f278:fcc0]) by MN0PR12MB6056.namprd12.prod.outlook.com
([fe80::4b75:36f4:f278:fcc0%5]) with mapi id 15.20.7784.017; Mon, 22 Jul 2024
09:02:11 +0000
From: Raslan Darawsheh <rasland@nvidia.com>
To: =?Windows-1252?Q?L=E1szl=F3_Moln=E1r?= <laszlo.molnar@ericsson.com>,
"users@dpdk.org" <users@dpdk.org>
Subject: Re: mlx5: is GTP encapsulation possible using the rte_flow api?
Thread-Topic: mlx5: is GTP encapsulation possible using the rte_flow api?
Thread-Index: AQHaoVu6ynByKyFHgkekNBeN6/vRdLIC54jy
Date: Mon, 22 Jul 2024 09:02:11 +0000
Message-ID: <MN0PR12MB6056AB9102C8DAA1BE043909CFA82@MN0PR12MB6056.namprd12.prod.outlook.com>
References: <ZjuY+KquiSHG0bjo@elx-5cg22853xc>
In-Reply-To: <ZjuY+KquiSHG0bjo@elx-5cg22853xc>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=nvidia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MN0PR12MB6056:EE_|DS0PR12MB7656:EE_
x-ms-office365-filtering-correlation-id: 3199f965-9bff-4306-40ec-08dcaa2cf8fe
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0; ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info: =?Windows-1252?Q?MsHnYQDEBWaFs9rVRnn4xQ5RfqvHfBdkSd6OGwasaYIrgkGRntyAQG5T?=
=?Windows-1252?Q?U+oUfA6LA8W/vrdVjis/chrdDOKM9k20JcYrbAS/hcXjvv7Yr9iWLtce?=
=?Windows-1252?Q?aGL9rS3n4AiKolZsEgWXSz4mv4F6IDgJOmKYHmpBrVS0nEVHd6ZATGmP?=
=?Windows-1252?Q?ZN3VC7nOR4fd8+DnPtRJxux8/xNGy3joWunqF9ZLwI9oy/+y65zMOT6d?=
=?Windows-1252?Q?37ZVswh4taXV+ygSLxcUxs6p94Jv3DVbiR9Yke3HnPsH5YVkLIbcYjk8?=
=?Windows-1252?Q?5wCrPsCARJ+V8kk9FNNDd9SBdYpEvrNhnvdmjThJiUy2EGIHtx0Hm6O2?=
=?Windows-1252?Q?ovDVWVgJiSPDXlx4DuRtuWAghecUYsNq/xR6vai5A9FEv7LG/vQbdH/T?=
=?Windows-1252?Q?oR7OgVpP3Wbo2AQ/ocaCpVF9RWzQ0eeG4RSH+OVK3mKvD+N1uEf5CmMs?=
=?Windows-1252?Q?KBXsOKnKIA/ihFLKipxz3oG+k5QYvujGfXqTbYN9md1qM5hGBfGEsccu?=
=?Windows-1252?Q?pcFonMNo/407Pu20iyF6slmfuAraX27sy9VyCdEAQaWhPXWO/x8bSGtr?=
=?Windows-1252?Q?BM2pt3APO7SHnmO4nReTv0Z62kzZNL8J5gyudwfTl5cVqM2Ba0XEdVot?=
=?Windows-1252?Q?1YqYA3QLIDsSztwFSyUbzCyUdUmcCJPIy2GJLEYDKf5D+jN+JtM1puox?=
=?Windows-1252?Q?Y8d6GI7xZxieA2+/MpNRsaobJd357vxx1xXKSdkInwkoOSsL4I693l9l?=
=?Windows-1252?Q?uQcvhlugqDct+J9gMZJrWLSZenENYf5nvcqlO9tSFM0jafb5uHwjkZom?=
=?Windows-1252?Q?vh+tf56Cc6M1h35F/JcHRUID87QmLwVRMrJzZ1XQH26mWRCVSOTqz9O9?=
=?Windows-1252?Q?wINzk4x7MYvIUC3yazFjXyCI9E0M0PixDTPVCacizVg/V42oy4ty4Vp0?=
=?Windows-1252?Q?XmNJsW+FKE8b0CTyYCWVMmh2k27RevI/ylpbhc1C8EBTAtnodCjkxrJf?=
=?Windows-1252?Q?nNNgxjMDDBuW1DT6n6+0h+w4A9oXko5bRJMNbB4fTZX1Ay8FfbBMLmjB?=
=?Windows-1252?Q?NpLs7DO4UB2CO7GbUda3UV+AVoczeHK9uIiI35KGobBgqzaKWBo6rUHj?=
=?Windows-1252?Q?Y7prx2nnQ0mgGjoIHsYBBaOP2/7TFsc2M8+mJg7E7zssasvSL3cMX+ln?=
=?Windows-1252?Q?dqdlEKUyNYGUZFOaW19wyUN3c16Ffu41dpRoePnJE11y1gtOAcGawRqM?=
=?Windows-1252?Q?n7nMFtsLdLEmRLm6YxTAuNJkNWBlHzOS71MLlYqSz/jbJafqHNL683Hs?=
=?Windows-1252?Q?/lXwN9yV5+GS39sWVYpd/z5dqUxvK8X31FvnYYgBEsjCksGtfHAgIgfP?=
=?Windows-1252?Q?SAahAe4z2uVo3IOfGu33e9C73yX+ko/ui0u2PebjKvJ1veKe8QK218DU?=
=?Windows-1252?Q?ZhlkyiI5kf11rWFzEoibbInxG4Ms4tIztlD/Er1jb6rN/XtUhNUAi5dT?=
=?Windows-1252?Q?XWlmAbNCptrPc1jCH0CB1jvxxPKuDA=3D=3D?=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:MN0PR12MB6056.namprd12.prod.outlook.com; PTR:; CAT:NONE;
SFS:(13230040)(376014)(366016)(1800799024)(38070700018); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?/IBWLqrWdqmzFbhI0ud6o5RWAEHa/Im3oLFqF8fZz2NAqx3O1pULvu0+?=
=?Windows-1252?Q?vroN6ng0RmAF/U5GYCBeMQSmfhYc1qTFBTtDrf6sffYUt2K65AWUiLmN?=
=?Windows-1252?Q?deCeZzvK9xE9idC8/3IHWZakdQINlCbMIzoSyjg6/fxCb+vWn79vgmEK?=
=?Windows-1252?Q?li8wfUnryLj/rX/o2Qwjs1kyxgShQe/5b8mkJaY1QqB8w8jAkdot+iEk?=
=?Windows-1252?Q?uEtCAV49Y1UNWo8XoVvCWiGakKm5mDIxIgNT+yt9xtfJ5WYgxuCPCmca?=
=?Windows-1252?Q?UODRqn7eI52iYvijZz6Xm+pkPwSKhOEhNIVPByvJ+pDhORUljEHc3dfK?=
=?Windows-1252?Q?/Hs6Z83W9us3RV+c5VXB+QqOj9VW4LIL4/oF7QPYjr1j1aA5S5N0rbR1?=
=?Windows-1252?Q?uz8Eeh8LxFzq0Iq98Sex0aUB6V1KVqJzG8/ulpaTixYZapkfaHwzoGwm?=
=?Windows-1252?Q?Ltjh/u1Bmf0hLI6zQQxIm0ojREZF1nPxpOjWRsbjnNHS+Obrp95w6fsN?=
=?Windows-1252?Q?70kaIXUvtjQTUGmdsWJGKzyE4BuYcS4S/5mfE1JXjjFvmzJsqn+pCzph?=
=?Windows-1252?Q?coYL8SPZBaNRvawD9y1hkGoqVeZZBGKAUvH/zxjiMswdkOcKV9dohZk5?=
=?Windows-1252?Q?gV8oPJ7BT0CLdDQUaflQ6e93qqJKpuIt/CSC+ljaDbJDAhSZBlWLuGkv?=
=?Windows-1252?Q?SAyCcDvOJNbsNpILNLr2gwSkvGLAp+gkXUtv/2K2HfSjNYs7Od5Hk5JX?=
=?Windows-1252?Q?eZI0A2oTbu2nCLXvrVaRdV5R1BEWw5xi4HEXwYuAkvJB/L/gb4d9UxCa?=
=?Windows-1252?Q?43DvEVA+86aFse+RC0PiMdk4BUePqb4nwqT4r9FfOKrczCTjIZovIVMo?=
=?Windows-1252?Q?GL4QmXlr3Fw87Mo7VfGj3AFNUf6snfAn8XKI0U/5Dnp/xnyO/xfpWwF5?=
=?Windows-1252?Q?SAI56FIg2pLWr1kunePOTZZQsVhlAJ4ANLHdyF3F3wlXUc5bJsXaYL3U?=
=?Windows-1252?Q?SahMdAdtjV5WTrytDej4qrhZrNuvx0o2/Ums3OTxA6p1urnesxQc/e5U?=
=?Windows-1252?Q?8vVswaE7Do5nCaSWie2fkG4dgQx+r5C6vEpd7bYT3QNY7jOxbaD3ADWd?=
=?Windows-1252?Q?75EzpKbZtc97Sprlul2xcFW3GhI0yqH0ollUtwwpduBWYtJ1IU8bJFtj?=
=?Windows-1252?Q?DWxodu1+lTlrQxfNPA86jBf2jJZNNj7eTnLMAh8coHj+sfdHV7mMADjE?=
=?Windows-1252?Q?6NFYj2eHKRzfxLX+veeCdVIT71PWrh1WTbwCOHG91tslvGCCFFuaVTSy?=
=?Windows-1252?Q?rTqW1QC8yGSkyiBzyhy0hxghSUQzH/bU3RhYNziD8dM2sx8hdHQ5q5Hh?=
=?Windows-1252?Q?UhLVkg0oYOc2yEhatA2vYuaKbk8dQjM+M7Qf4Df0tOafNGDn9ZEiBIdu?=
=?Windows-1252?Q?IZUJ1DwVitoH8wwgRnLseXO626wlyvw1mR6z/xvhxTrplXjOTpmNNt6e?=
=?Windows-1252?Q?pKbBbJ3kWzX8kb2BIPBFjn00DPvHhKhabrogJwl1YUwRq8wFTvHcst+q?=
=?Windows-1252?Q?lQjjiDQj7Hzp/Zg8ewStJdU9xffv9pnJKtM7/1sVxB3ZRfen7h6ray8c?=
=?Windows-1252?Q?XczZBEj597ddRxZOBP0XjqHqkuummnw/98t57EurY1TsfhRC03H8Kpwp?=
=?Windows-1252?Q?sCF7G3Wc/YMdx+6McJDieieMpQVIXQcRQaVgNx/hfiokAP9UqTpZBw?=
=?Windows-1252?Q?=3D=3D?=
Content-Type: multipart/alternative;
boundary="_000_MN0PR12MB6056AB9102C8DAA1BE043909CFA82MN0PR12MB6056namp_"
MIME-Version: 1.0
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN0PR12MB6056.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3199f965-9bff-4306-40ec-08dcaa2cf8fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2024 09:02:11.2243 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CkKPZgYPRGk2m3MVNkdFnL/wdYI9SR9dD8WYc69f/v+Z5pWgxh4yWRvw/T1BthgS14vgOnxdIhAh97WLUF8R3A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7656
X-BeenThere: users@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK usage discussions <users.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/users>,
<mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/users>,
<mailto:users-request@dpdk.org?subject=subscribe>
Errors-To: users-bounces@dpdk.org
--_000_MN0PR12MB6056AB9102C8DAA1BE043909CFA82MN0PR12MB6056namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hello,
> Hi All,
>I wonder whether it would be possible to implement HW accelerated GTP
>encapsulation (as a first step) functionality using a Bluefield 2 NIC
>and the rte_flow API?
yes should be supported.
>The encapsulation would need to work between different ports using
>hairpin queues.
>Let's say I already have the rules in dpdk-testpmd that remove the
>original ETH header using raw_decap, and add the new ETH/IP/UDP/GTP
>using raw_encap.
>Now I would need to update some header fields (payload length for
>pv4, udp, gtp). I would use "modify_field op add", but I found no way
>I can access the payload length field for UDP and GTP.
These are usually calculated by the NIC on ecnap so you don't need to set t=
hese fields or modify them.
>For example, when I try to access the UDP payload length field by using
>"dst_type udp_port_src dst_offset 32" in the "modify_field" action,
>I get a "destination offset is too big: Invalid argument" error.
In general and in MLX5 we don=92t support changing the length field of the =
packet
>This seems to be caused by a check in the mlx5 driver, which is a bit
>surprising as the documentation in rte_flow.rst (DPDK version 24.03)
>says that:
>``offset`` allows going past the specified packet field boundary to
>copy a field to an arbitrary place in a packet,
>Is this just a driver limitation or an HW limitation? Or could a flex
>item solve this?
>Thanks, Laszlo
Kindest regards
Raslan Darawsheh
--_000_MN0PR12MB6056AB9102C8DAA1BE043909CFA82MN0PR12MB6056namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang=3D"en-PS" link=3D"#467886" vlink=3D"#96607D" style=3D"word-wrap:=
break-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Hell=
o,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
> </o:p></span></p>
<div id=3D"mail-editor-reference-message-container">
<div>
<div>
<p class=3D"MsoNormal"><b><span lang=3D"EN-US">> </span></b><span style=
=3D"font-size:11.0pt">Hi All,<br>
<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">I wonder whether it would be possible to implement =
HW accelerated GTP<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">encapsulation (as a first step) functionality using=
a Bluefield 2 NIC<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">and the rte_flow API?<br>
<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">yes =
should be supported.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">The encapsulation would need to work between differ=
ent ports using<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">hairpin queues.<br>
<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">Let's say I already have the rules in dpdk-testpmd =
that remove the<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">original ETH header using raw_decap, and add the ne=
w ETH/IP/UDP/GTP<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">using raw_encap.<br>
<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">Now I would need to update some header fields (payl=
oad length for<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">pv4, udp, gtp). I would use "modify_field op a=
dd", but I found no way<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">I can access the payload length field for UDP and G=
TP.</span><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Thes=
e are usually calculated by the NIC on ecnap so you don't need to set these=
fields or modify them.</span><span style=3D"font-size:11.0pt"><br>
<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">For example, when I try to access the UDP payload l=
ength field by using<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">"dst_type udp_port_src dst_offset 32" in =
the "modify_field" action,<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">I get a "destination offset is too big: Invali=
d argument" error.<br>
<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">In g=
eneral and in MLX5 we don=92t support changing the length field of the pack=
et<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt"><br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">This seems to be caused by a check in the mlx5 driv=
er, which is a bit<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">surprising as the documentation in rte_flow.rst (DP=
DK version 24.03)<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">says that:<br>
<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></s=
pan><span style=3D"font-size:11.0pt">``offset`` allows going past the speci=
fied packet field boundary to<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></s=
pan><span style=3D"font-size:11.0pt">copy a field to an arbitrary place in =
a packet,<br>
<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">Is this just a driver limitation or an HW limitatio=
n? Or could a flex<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">item solve this?<br>
<br>
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt">></span><span sty=
le=3D"font-size:11.0pt">Thanks, Laszlo</span><span lang=3D"EN-US" style=3D"=
font-size:11.0pt"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><o:p=
> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Kind=
est regards<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Rasl=
an Darawsheh<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>
--_000_MN0PR12MB6056AB9102C8DAA1BE043909CFA82MN0PR12MB6056namp_--