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 EF27743AF1;
Mon, 12 Feb 2024 21:09:55 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 702C540274;
Mon, 12 Feb 2024 21:09:55 +0100 (CET)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
(mail-dm6nam10on2082.outbound.protection.outlook.com [40.107.93.82])
by mails.dpdk.org (Postfix) with ESMTP id EC7164026E
for <dev@dpdk.org>; Mon, 12 Feb 2024 21:09:53 +0100 (CET)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=UAgO5U1XvkycmcjK8ZUJ/WGjhj8nBgxRMJi4jTAf6appVWcH8V4uJBaXA4qRsXLlmgMgM9iiUjmzenxGgvUtg1+M0VFVbRytr7/OKp9xHwB6cFUGsu9vStyF8L/uxu84tQu+72lHvqX0+NStR2tg3Ee3QeaO8A4l7LkMoNUMwfU7u1R+HBVQhDFu1KBDUFiB1fmnmi/FRpP2WvEa7AP/ebFl/nXudpKLxpfeLWXvNcm2V19b/9D+ZTeDS0pdtx6BHmBuPvcP1nrEHhzNAN/4UjdHpkI5waPYeZbNAjwy2P/W1J7HheUI+vq1o9/x/beN+bDZX22IQXVQatVxYXn6Jw==
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=mO2fNHcAzg9zU8YMiRu/zm9ZblEg6+WHYaC7ZzSH8xo=;
b=mWZUS59879Xjn7+v9eMcg/hIfORQHg9AOMVgfXlLkAIY60DG2Adh0+U584Zk8Q8SZKqxFxZtXJBJvtN3p9yHemtbPSz70CiYGK4eDrTpp1f1GsrjzU5bNTfod29NKgxVnfORO0jzd0l6GdoQz84ZgUAU1UUPA0D7d3ZfKD1Sdh3+v/AAu6THvQERXj0W+8s8d+ytU/inRjOgD7MYKKjn0tNA+ivfuEzW6xdYBznYaSMU7xiYMB+x0lK5pyfQKTHLk565UTz5EL5FZyITW6lfsKhUmKbCGcgFBSO2BSiz7Ziyf+02sCgbsT8GsqMw8dTXHVqG8fcZg5SE5RjnoVbd4Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=mO2fNHcAzg9zU8YMiRu/zm9ZblEg6+WHYaC7ZzSH8xo=;
b=Cx3CoIAGuvi1raaotyOmLIZetAxrEQC1Beu9xlcx62kzGAOwnhbg06d40yABA31hYoz6eso1CTz5TrNwvJ9gtKIpu3tdfTH+TgJP8i17ff3yC+kunjhDyMwHuN0ncvULHTqF5HLB+vffKQ4oCde0CbMEDoldG+hrltg0Lc974qs=
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=amd.com;
Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11)
by CY8PR12MB7099.namprd12.prod.outlook.com (2603:10b6:930:61::17)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.10; Mon, 12 Feb
2024 20:09:51 +0000
Received: from CH2PR12MB4294.namprd12.prod.outlook.com
([fe80::3ec7:6339:1c14:c529]) by CH2PR12MB4294.namprd12.prod.outlook.com
([fe80::3ec7:6339:1c14:c529%4]) with mapi id 15.20.7292.022; Mon, 12 Feb 2024
20:09:51 +0000
Message-ID: <19b7d3db-f142-49fa-976d-a180f03d7a0b@amd.com>
Date: Mon, 12 Feb 2024 20:09:47 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] ethdev: introduce encap hash calculation
Content-Language: en-US
To: Ori Kam <orika@nvidia.com>, Dariusz Sosnowski <dsosnowski@nvidia.com>,
"cristian.dumitrescu@intel.com" <cristian.dumitrescu@intel.com>,
"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Raslan Darawsheh <rasland@nvidia.com>
References: <20240128093943.4461-1-orika@nvidia.com>
<20240208090919.11565-1-orika@nvidia.com>
<50189a77-2c1f-4b31-935d-506fa98d22af@amd.com>
<MW2PR12MB4666BE1F8D4E64E034E847C4D6492@MW2PR12MB4666.namprd12.prod.outlook.com>
<55623d61-c2e2-49b4-873b-8d1aa78ce142@amd.com>
<MW2PR12MB46664661B2732AA5AF31D14BD6482@MW2PR12MB4666.namprd12.prod.outlook.com>
From: Ferruh Yigit <ferruh.yigit@amd.com>
Autocrypt: addr=ferruh.yigit@amd.com; keydata=
xsFNBGJDD3EBEAC/M7Tk/DfQSmP1K96vyzdhfSBzlCaGtcxNXorq4fALruqVsD3oi0yfyEz9
4YN8x7py0o9EL8ZdpOX0skc0AMCDAaw033uWhCn0GLMeGRKUbfOAPvL6ecSDvGD7CJIO9j0J
eZUvasBgPdM/435PEr9DmC6Ggzdzt8IuG4PoLi5jpFSfcqxZFCCxLUDEo/w0nuguk2FTuYJg
B2zEZ4JTBZrw7hIHiFh8D8hr6YA6a5uTofq1tr+l048lbtdFUl8TR0aIExVzE4Z8qKZlcE+9
RQaewjK5Al1jLE4sHdmd3GN+IvgDF3D/fLsi25SKJDeGSdeHkOmaX0qGeM4WKIfU6iARRCiQ
N3AmBIxZ/A7UXBKLaOyZ+/i3sE6Wb53nrO4i8+0K2Qwyh6LjTeiJAIjYKN43ppxz3DaI+QwQ
vI+uyHr4Gg0Da9EPPz/YyKauSeOZCfCB5gIfICO0j6x0SCl8uQ2nLpjxcZkf0gjcwUzP3h+S
3x6NfDji9YEij0zczW/dcSpGgZ6vsFpPrtnP9ZXy6J53yp0kJtOJoOlkEFFdU2yCZnCDseum
CoudmGLZVvS0/DzHDJejq+3kK3FDGktZBOxZIIpal+nFqS7lVgOZc4+huVv3jyhzoAUOEyXA
XK5j6o7g8STUY+z33QNnHpdLvecMwuzmvqy0jR54yAbZ64mB9QARAQABzSNGZXJydWggWWln
aXQgPGZlcnJ1aC55aWdpdEBhbWQuY29tPsLBlwQTAQgAQQIbAwULCQgHAgYVCgkICwIEFgID
AQIeAQIXgAIZARYhBEm7aYjps5XGsPHCElRTPtCKKm/6BQJkdyEEBQkE3meNAAoJEFRTPtCK
Km/6UdcP/0/kEp49aIUhkRnQfmKmNVpcBEs4NqceNCWTQlaXdEwL1lxf1L49dsF5Jz1yvWi3
tMtq0Mk1o68mQ7q8iZAzIeLxGQAlievMNE0BzLWPFmuX+ac98ITBqKdnUAn6ig5ezR+jxrAU
58utUszDl16eMabtCu76sINL5izB8zCWcDEUB4UqM8iBSQZ7/a7TSBVS0jVBldAORg1qfFIs
cGMPQn/skhy3QqbK3u3Rhc44zRxvzrQJmhY6T1rpeniHSyGOeIYqjpbpnMU5n1VWzQ4NXvAD
VDkZ4NDw6CpvF4S2h2Ds7w7GKvT6RRTddrl672IaLcaWRiqBNCPm+eKh4q5/XkOXTgUqYBVg
Ors8uS9EbQC/SAcp9VHF9fB+3nadxZm4CLPe5ZDJnSmgu/ea7xjWQYR8ouo2THxqNZtkercc
GOxGFxIaLcJIR/XChh9d0LKgc1FfVARTMW8UrPgINVEmVSFmAVSgVfsWIV+NSpG9/e90E4SV
gMLPABn1YpJ8ca/IwqovctqDDXfxZOvCPOVWTzQe/ut767W+ctGR1kRkxWcz470SycOcY+PW
VRPJd91Af0GdLFkwzZgNzkd6Gyc9XXcv4lwwqBLhWrBhqPYB0aZXIG1E/cVTiRp4dWpFHAFD
DcuLldjIw93lCDsIeEDM9rBizGVMWEoeFmqSe7pzGTPXzsFNBGJDD3EBEAC8fBFQHej8qgIG
CBzoIEd1cZgPIARlIhRudODXoNDbwA+zJMKtOVwol3Hh1qJ2/yZP11nZsqrP4fyUvMxrwhDe
WBWFVDbWHLnqXMnKuUU1vQMujbzgq/4Rb9wSMW5vBL6YxhZng+h71JgS/9nVtzyaTtsOTrJi
6nzFSDx6Wbza2jYvL9rlK0yxJcMEiKwZQ/if4KcOesD0rtxomU/iSEv6DATcJbGXP6T93nPl
90XksijRKAmOwvdu3A8IIlxiSSVRP0lxiHOeR35y6PjHY2usfEDZZOVOfDfhlCVAIBZUZALv
VmFOVSTYXeKgYa6Ooaf72+cHM3SgJIbYnevJfFv8YQW0MEAJ/IXE7B1Lk+pHNxwU3VBCrKnA
fd/PTvviesuYRkrRD6qqZnINeu3b2DouVGGt2fVcGA38BujCd3p8i7azoGc7A6cgF7z9ETnr
ANrbg1/dJyDmkDxOxVrVquTBbxJbDy2HaIe9wyJTEK2Sznpy62DaHVY+gfDQzexBXM10geHC
IIUhEnOUYVaq65X3ZDjyAQnNDBQ4uMqSHZk8DpJ22X+T+IMzWzWl+VyU4UZXjkLKPvlqPjJk
1RbKScek5L2GhxHQbPaD76Hx4Jiel0vm2G+4wei8Ay1+0YRFkhySxogU/uQVXHTv63KzQMak
oIfnN/V2R0ucarsvMBW+gwARAQABwsF8BBgBCAAmAhsMFiEESbtpiOmzlcaw8cISVFM+0Ioq
b/oFAmR3IPsFCQTeZ44ACgkQVFM+0Ioqb/qINhAAtcor9bevHy22HvJvXX17IOpPSklZJAeQ
Az43ZEo5kRlJ8mElc2g3RzYCvL/V3fSiIATxIsLq/MDtYhO8AAvklxND/u2zeBd7BkRZTZZX
W1V1cM3oTvfx3LOhDu4f2ExQzCGdkzbXTRswSJIe1W0qwsDp+YPekbrsKp1maZArGeu+6FuW
honeosIrWS98QJmscEhP8ooyJkLDCCOgEk+mJ/JBjzcJGuYn6+Iy/ApMw/vqiLGL1UWekcTA
g18mREHqIR+A3ZvypIufSFB52oIs1zD/uh/MgmL62bY/Cw6M2SxiVxLRsav9TNkF6ZaNQCgn
GqifliCEMvEuLZRBOZSYH2A/PfwjYW0Ss0Gyfywmb2IA990gcQsXxuCLG7pAbWaeYazoYYEQ
NYmWatZNMAs68ERI2zvrVxdJ/fBWAllIEd0uQ4P05GtAHPdTIDQYp545+TPV7oyF0LfXcsQs
SFVZE6igdvkjfYmh+QOrHGZvpWXLTmffVf/AQ81wspzbfxJ7sYM4P8Mg5kKOsaoUdyA/2qVe
cMh1CLUHXF1GlofpGbe1lj4KUJVse5g3qwV7i9VrseA8c4VIZewdIjkzAhmmbxl+8rM/LKBH
dZUMTzME5PFCXJIZ83qkZQ795MTe2YScp9dIV7fsS5tpDwIs7BZNVM1l3NAdK+DLHqNxKuyO 8Zk=
In-Reply-To: <MW2PR12MB46664661B2732AA5AF31D14BD6482@MW2PR12MB4666.namprd12.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0525.GBRP123.PROD.OUTLOOK.COM
(2603:10a6:600:2c5::8) To CH2PR12MB4294.namprd12.prod.outlook.com
(2603:10b6:610:a9::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|CY8PR12MB7099:EE_
X-MS-Office365-Filtering-Correlation-Id: 097c4516-5e2d-46f5-746e-08dc2c0691f4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: DLrW0ys8UVN1cGZQvR3cS54+G0nKaKaOA/rzU3BgDl4z76I2ffbXlVNWZLKosIuqS/6qgniTGfgeZzjj4bDGc/Du4iUNlGJ1PU5NUr38n5fUttG8vuiW8Jy/GLWRgXLlAkqXX2wxD3rb0ALsBWHGPy2HIS20kUDf8L4+DsjW2gAiB4pRC1DPaWK18ZDgEJKrlDJl0DfQxusXSApb9ifTYVC4AxByTG65HkUD1iJI+IM7eLmDYlbS+ujkk74zyxH3d1JPy8z0Jyw6r1wQDiOJohByPvIb2y8N/pwESnYX0IUPdKluCs0mDJawu8GnqxDrgM2qMiaPv4Acy4IxAPpyAtu6JHmJm73c+M9WCGlEENsRT8uzLb7Daby2TTCbbcNsOAkOiU1Su5j+z/IozziO7KvC4hBiRCsfj0X/wmXujl2IMS0Ye/xezSrD8LLQueYvzwmuiH+1yOiP3e2nFIiK8gB59yqhQ2uYxuOmLZSZAy782rePEbfU0wnmkimeh8VXySXCvs3dWzrUiiT49KgnuTd75gCgnmf8JY4CSPXCIJPjfyOz4J3dzM8N0i5D9zPZ
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE;
SFS:(13230031)(346002)(376002)(39860400002)(396003)(366004)(136003)(230922051799003)(230273577357003)(64100799003)(451199024)(1800799012)(186009)(38100700002)(44832011)(2906002)(5660300002)(31686004)(41300700001)(86362001)(26005)(83380400001)(4326008)(31696002)(2616005)(66899024)(54906003)(6486002)(66476007)(6512007)(53546011)(6506007)(36756003)(478600001)(8676002)(66556008)(8936002)(110136005)(316002)(6666004)(66946007);
DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OUlReVJkbjNmOHlTUDJ2VWh2YWhGV3JudVl4bEZRV3ZtOWNCUWh4dXdaMC9a?=
=?utf-8?B?VlpNdFlINWRIWmsydHJtaHRQVjRuT0E3blVITWZObFpRN2ZCVlFid3hzWXVU?=
=?utf-8?B?cW93aDZ4WUM1eTlwZlZaYzFMUFZTVm01ZE1WblVjQm5SLys2aVIwWUlPWmVS?=
=?utf-8?B?OU51OHhJYjBUUmdpQ3lIODY4Z0hUVkNCVXBTTUl2a0dyZHVMdUxJWXk1SHRv?=
=?utf-8?B?S3FCV2lJNXRRNzh5am5MODJDeHQ2OHZrS2x1ZS9JOE03SUt4Sk5VemZUSG5x?=
=?utf-8?B?RTNDSjEwY0hUVEtGOFhRZEUvcW1iTDJOWXVJZStHOUJDeStnVUdpTW9heS82?=
=?utf-8?B?dXZJMVpoNVBsSEM5bjB4Y2pQU3pzQ3R6R0VjVmdKWldDbXhMOFFTNHd2YmVN?=
=?utf-8?B?clFIRjU1Qk9xRy9lSHN0MXNrVVNsQWR1TDNWM0tjQTErSWNlRUMyN2ZvZFBy?=
=?utf-8?B?Wkc5RVBFaFB4Qzk5M01sczJHQTdtZHNwN2xkd1BlN1VKZzRsK2hnaVhORVFx?=
=?utf-8?B?ZDhEem8xa05TRlE5bmlDVFBPeEd1OWt2c0hnclZJTkZiTGxJZytuM0dvTlAv?=
=?utf-8?B?ZnQraURacDcvekpRKzlLWVlmYXVORzZ1NkdmdmtoZ2ZnNHV5WVh1VnRwZUgz?=
=?utf-8?B?WGVkTUxpTEFjMDN6d2pPeVhvV3B2Kzd5RlJxaGR2d0lXS1NGZGo2d1ZIYzR0?=
=?utf-8?B?d1FBQ1dXUEEvWnN1cTE3bWtZQ3VHZk1xVXRHYkZzMC9MUit0T0V1OEVnNG5J?=
=?utf-8?B?a2RVeWd3ekljcmNWSS9jeG5xSjBld0FSWk5kS0JtbzdVWlFoeTFONGVIRytN?=
=?utf-8?B?Vm03MDIzV1dKdUhkMURuS2p4TlJXUm9uYXBHTmo4d2pLUk93YjBicWw2QXBH?=
=?utf-8?B?UG0vbTJ5NWNmK3JMV0ZScXhVd3pZNlZxTFQxcTA5am00SWtOQ3BVUDFKcTdT?=
=?utf-8?B?UUtzYUQ0aE5qbTEzYkQrc0JWZXcyYXBUeVcvT29jTC95em1aOTdmM2gyYTg0?=
=?utf-8?B?Mk9SZFNIMHdkMWhOV1J5dEJOUzZGM0wyUXhJTmp4UFFtMzZQUlJBZFlJanZv?=
=?utf-8?B?cFlJakRHU2UzUVl3OXRPTTNJRU9VczJmNm44SzdoRU9ReHJ4cjU4YUIvTi9u?=
=?utf-8?B?WFlXY3hCaGtmcWFDcFlLc3VxTlppM2oyTFpHbDVETmFwZzBsV1g4SmZNdWFh?=
=?utf-8?B?SUwwRUhhRVVWbGRQelBRVjdNanVSdkY3MitKcUlnL3p5eXVIanRrZzFnNnJx?=
=?utf-8?B?TmVTcFNGWDhuRW9KNzdHWmk3ZERscmJNMHJab21NNEdkSUlXMDJsbTRvdnpW?=
=?utf-8?B?WmJ1MkdzVWFvemcwa1UyZnJWK0pZN1BVR1doZDdMYXpoYm5CVnlUa1FURlFq?=
=?utf-8?B?ZmNPdXhtaWExWDhDQ3UxNGdoVUh0N2gyWlRuZUhiaHlmb1ZPaDZaNmdMeElo?=
=?utf-8?B?NFZHcW5yUzlxeGkrWTBJMzk0WFBIYlpuNTFXKzgwTHB1OTRiam45a2NHd05R?=
=?utf-8?B?SlhXWHRwdWpPK2hPVzV3eEJRT2tqa1dpM1dsV2lCWm0xSnVkTW1jMUtjeHFC?=
=?utf-8?B?djVDOEw5MDUwNzhxbFZ2UXQxWHg1M1dHcGZHWnZtajl5VzVQWDR1MzlNMWFG?=
=?utf-8?B?cXloM0R6Z21IeTcrRHhMVXV0c0FtenF6VWVVT3UxMURneE0ybmN2UlpVNmY1?=
=?utf-8?B?bmdManRocitGQkl4NW5XK0MwWk5raFIwcWRHTGJFQ1VZYVJqOW5jeExpYjNz?=
=?utf-8?B?VzE5ZGRpZUFJQnVoQklDMnU0c2JxNm9pbmF0YjZBY3B6RGEzNWFuUmNmend6?=
=?utf-8?B?UC9aa1JHRnBRMElUSkxQSVBPZGw1TnpaQ1NKVzMzRERVNXpLQXFET1NSSVda?=
=?utf-8?B?Q012alNsOUkwOVE3b1Z2YS8zaUNlMHdBUEVGdktXcGZlQ1JWMzI1NzZHLy9o?=
=?utf-8?B?d25wbmkzcExRT1ZYbmNxY0xvd250WGZUcm4wcXFzdU9rZ2ZYWkJJR2ZOMFZv?=
=?utf-8?B?dkpCRWpQbG8wNUR0T0VYdjlydU5ZM1dhTTNwUnhnTFF0YTlEa1Z0TExZWWNF?=
=?utf-8?B?V1M3dzZNNkQ5YksxdG9kRnFmTjZPdTBtb1I2TjNlVHlRYUVtSXcyNzE1c3ht?=
=?utf-8?Q?mZ1mGsJK6/PBLm1T2fSN0ZqTR?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 097c4516-5e2d-46f5-746e-08dc2c0691f4
X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2024 20:09:51.3067 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: RanFSBvDc715JizMILiDNpC6dG4DOoY/X+zpvcDSp7jMGqLdYZRqCQodDmZGCye8
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7099
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
On 2/12/2024 6:44 PM, Ori Kam wrote:
> Hi Ferruh
>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@amd.com>
>> Sent: Monday, February 12, 2024 7:05 PM
>>
>> On 2/11/2024 7:29 AM, Ori Kam wrote:
>>> Hi Ferruh,
>>>
>>>> -----Original Message-----
>>>> From: Ferruh Yigit <ferruh.yigit@amd.com>
>>>> Sent: Thursday, February 8, 2024 7:13 PM
>>>> To: Ori Kam <orika@nvidia.com>; Dariusz Sosnowski
>>>>
>>>> On 2/8/2024 9:09 AM, Ori Kam wrote:
>>>>> During encapsulation of a packet, it is possible to change some
>>>>> outer headers to improve flow destribution.
>>>>> For example, from VXLAN RFC:
>>>>> "It is recommended that the UDP source port number
>>>>> be calculated using a hash of fields from the inner packet --
>>>>> one example being a hash of the inner Ethernet frame's headers.
>>>>> This is to enable a level of entropy for the ECMP/load-balancing"
>>>>>
>>>>> The tunnel protocol defines which outer field should hold this hash,
>>>>> but it doesn't define the hash calculation algorithm.
>>>>>
>>>>> An application that uses flow offloads gets the first few packets
>>>>> (exception path) and then decides to offload the flow.
>>>>> As a result, there are two
>>>>> different paths that a packet from a given flow may take.
>>>>> SW for the first few packets or HW for the rest.
>>>>> When the packet goes through the SW, the SW encapsulates the packet
>>>>> and must use the same hash calculation as the HW will do for
>>>>> the rest of the packets in this flow.
>>>>>
>>>>> the new function rte_flow_calc_encap_hash can query the hash value
>>>>> fromm the driver for a given packet as if the packet was passed
>>>>> through the HW.
>>>>>
>>>>> Signed-off-by: Ori Kam <orika@nvidia.com>
>>>>> Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
>>>>>
>>>>
>>>> <...>
>>>>
>>>>> +int
>>>>> +rte_flow_calc_encap_hash(uint16_t port_id, const struct rte_flow_item
>>>> pattern[],
>>>>> + enum rte_flow_encap_hash_field dest_field, uint8_t
>>>> hash_len,
>>>>> + uint8_t *hash, struct rte_flow_error *error)
>>>>> +{
>>>>> + int ret;
>>>>> + struct rte_eth_dev *dev;
>>>>> + const struct rte_flow_ops *ops;
>>>>> +
>>>>> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>>>> + ops = rte_flow_ops_get(port_id, error);
>>>>> + if (!ops || !ops->flow_calc_encap_hash)
>>>>> + return rte_flow_error_set(error, ENOTSUP,
>>>>> +
>>>> RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
>>>>> + "calc encap hash is not supported");
>>>>> + if ((dest_field == RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT &&
>>>> hash_len != 2) ||
>>>>> + (dest_field == RTE_FLOW_ENCAP_HASH_FIELD_NVGRE_FLOW_ID
>>>> && hash_len != 1))
>>>>>
>>>>
>>>> If there is a fixed mapping with the dest_field and the size, instead of
>>>> putting this information into check code, what do you think to put it
>>>> into the data structure?
>>>>
>>>> I mean instead of using enum for dest_filed, it can be a struct that is
>>>> holding enum and its expected size, this clarifies what the expected
>>>> size for that field.
>>>>
>>>
>>> From my original email I think we only need the type, we don't need the
>> size.
>>> On the RFC thread there was an objection. So I added the size,
>>> If you think it is not needed lets remove it.
>>>
>>
>> I am not saying length is not needed, but
>> API gets 'dest_field' & 'hash_len', and according checks in the API for
>> each 'dest_field' there is an exact 'hash_len' requirement, this
>> requirement is something impacts user but this information is embedded
>> in the API, my suggestion is make it more visible to user.
>>
>> My initial suggestion was put this into an object, like:
>> ```
>> struct x {
>> enum rte_flow_encap_hash_field dest_field;
>> size_t expected size;
>> } y[] = {
>> { RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT, 2 },
>> { RTE_FLOW_ENCAP_HASH_FIELD_NVGRE_FLOW_ID, 1 }
>> };
>> ```
>>
>> But as you mentioned this is a limited set, perhaps it is sufficient to
>> document size requirement in the "enum rte_flow_encap_hash_field" API
>> doxygen comment.
>
> Will add it to the doxygen.
>
>>
>>
>>
>>>>> + return rte_flow_error_set(error, EINVAL,
>>>>> +
>>>> RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
>>>>> + "hash len doesn't match the
>>>> requested field len");
>>>>> + dev = &rte_eth_devices[port_id];
>>>>> + ret = ops->flow_calc_encap_hash(dev, pattern, dest_field, hash,
>>>> error);
>>>>>
>>>>
>>>> 'hash_len' is get by API, but it is not passed to dev_ops, does this
>>>> mean this information hardcoded in the driver as well, if so why
>>>> duplicate this information in driver instead off passing hash_len to driver?
>>>
>>> Not sure I understand, like I wrote above this is pure verification from my
>> point of view.
>>> The driver knows the size based on the dest.
>>>
>>
>> My intention was similar to above comment, like dest_field type
>> RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT implies that required size should
>> be
>> 2 bytes, and it seems driver already knows about this requirement.
>
> That is correct, that is why I don't think we need the size, add added it
> only for validation due to community request.
>
>>
>> Instead, it can be possible to verify 'hash_len' in the API level, pass
>> this information to the driver and driver use 'hash_len' directly for
>> its size parameter, so driver will rely on API provided 'hash_len' value
>> instead of storing this information within driver.
>>
>> Lets assume 10 drivers are implementing this feature, should all of them
>> define MLX5DR_CRC_ENCAP_ENTROPY_HASH_SIZE_16 equivalent
>> enum/define
>> withing the driver?
>
> No, the driver implements hard-coded logic, which means that it just needs to know
> the dest field, in order to know what hash to calculate
> It is possible that for each field the HW will calculate the hash using different algorithm.
>
OK if HW already needs to know the size in advance, lets go with enum
doxygen update only.
> Also it is possible that the HW doesn't support writing to the expected field, in which case we
> want the driver call to fail.
>
> Field implies size.
> Size doesn't implies field.
>
>>
>>>>
>>>>
>>>>> + return flow_err(port_id, ret, error);
>>>>> +}
>>>>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
>>>>> index 1267c146e5..2bdf3a4a17 100644
>>>>> --- a/lib/ethdev/rte_flow.h
>>>>> +++ b/lib/ethdev/rte_flow.h
>>>>> @@ -6783,6 +6783,57 @@ rte_flow_calc_table_hash(uint16_t port_id,
>>>> const struct rte_flow_template_table
>>>>> const struct rte_flow_item pattern[], uint8_t
>>>> pattern_template_index,
>>>>> uint32_t *hash, struct rte_flow_error *error);
>>>>>
>>>>> +/**
>>>>> + * @warning
>>>>> + * @b EXPERIMENTAL: this API may change without prior notice.
>>>>> + *
>>>>> + * Destination field type for the hash calculation, when encap action is
>>>> used.
>>>>> + *
>>>>> + * @see function rte_flow_calc_encap_hash
>>>>> + */
>>>>> +enum rte_flow_encap_hash_field {
>>>>> + /* Calculate hash placed in UDP source port field. */
>>>>>
>>
>> Just recognized that comments are not doxygen comments.
>
> Thanks,
> Will fix.
>>
>>>>> + RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT,
>>>>> + /* Calculate hash placed in NVGRE flow ID field. */
>>>>> + RTE_FLOW_ENCAP_HASH_FIELD_NVGRE_FLOW_ID,
>>>>> +};
>>>>>
>>>>
>>>> Indeed above enum represents a field in a network protocol, right?
>>>> Instead of having a 'RTE_FLOW_ENCAP_HASH_' specific one, can re-using
>>>> 'enum rte_flow_field_id' work?
>>>
>>> Since the option are really limited and defined by standard, I prefer to have
>> dedicated options.
>>>
>>
>> OK, my intention is to reduce the duplication. Just for brainstorm, what
>> is the benefit of having 'RTE_FLOW_ENCAP_HASH_' specific enums, if we
>> can present them as generic protocol fiels, like
>> 'RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT' vs
>> 'RTE_FLOW_FIELD_UDP_PORT_SRC,'?
>
> I guess you want to go with 'RTE_FLOW_FIELD_UDP_PORT_SRC
> right?
>
I just want to discuss if redundancy can be eliminated.
> The main issue is since the options are really limited and used for a very dedicated function.
> When app developers / DPDK developers will look at it, it will be very unclear what is the use of this enum.
> We already have an enum for fields. Like you suggested we could have used it,
> but this will show much more option than there are really.
>
OK, lets use dedicated enums to clarify to the users the specific fields
available for this set of APIs.
Btw, is boundary check like following required for the APIs:
```
if (dest_field > RTE_FLOW_ENCAP_HASH_FIELD_NVGRE_FLOW_ID)
return -EINVAL;
```
In case user pass an invalid value as 'dest_filed'
(Note: I intentionally not used MAX enum something like
'RTE_FLOW_ENCAP_HASH_FIELD_MAX' to not need to deal with ABI issues in
the future.)