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 4E4CF43B02; Mon, 12 Feb 2024 18:05:15 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D01EB402C8; Mon, 12 Feb 2024 18:05:14 +0100 (CET) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2054.outbound.protection.outlook.com [40.107.237.54]) by mails.dpdk.org (Postfix) with ESMTP id 1BE4440279 for ; Mon, 12 Feb 2024 18:05:13 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CmTICF3ksKQnUg9w0NG4Evqm+n6JhZtF6ij9Ph3rZSewQrggWwmpkIlslgX5cR0OVhhKGH2yChkVxtN/83XK5EZE6E9NorYvyXbfrIanNVfTc4AA/yjL3gUbJb2WgR89Qic/Uzfhk+gkYgTFGHD28z817tmcLzaZG+UTLrpAq96PC7+5HDEVQsIyYPxtuDZKwrt438a0zmyJN2LsC6TKmPI7yEDzZdqII/ZHxmG6y0XQDiKSmmu8RERa+/hCBo5a3Q7yidOZ6v18gr5R6ZroIQlA6+V+uBiqy2QLpfXH6baVDZ9Ker4ckearL57vxlA+5Ug4J9Vgy+ti5qc2+7/MYw== 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=yaaQoRqVds3QY2No7tBIS5NZrfJBtdW239ipQIZTO+M=; b=hTrWyTtYClfL+IHLbD3ZCnDp+4AayfLS984Ot03jBbri1q7D7+nDlJjs/vazC4hb4O5wPH2HM2psD1ruIZlNNe066uin/j2Gvebxtyq1wfJ+oDMczySwQ4bhnDmalrHsZcXzD0Ska2E8bLjkKqT1a+zkxC28mo6WW3vD+hQnZDDhharQBzSngiP8TTrZBSQdu8+9HJqeQQzAcf7G44K4DCml96p3Jla3WXm+07fWe5omiB7C/h6QAfNBEYkMS1rIf61+tBGi2T+IChPScQneHMzbmNHTPTZwKpSGiH7DgzS9OqrPjNxRtsU3SAK+QqZW3FIYp2HIRKXI0msO6NKTDw== 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=yaaQoRqVds3QY2No7tBIS5NZrfJBtdW239ipQIZTO+M=; b=Rbe57HK2ACBc58YRp8wFy5a0j6MBZYMjK9vFIiv1O1dAIeT9ta6ayM79qKnH9+T3SUhqDlUC30rGqjfgsYLuqAqT6Gf8lFmiXXBkT1/TxqYfSNbjBkqUsLasLQorJ5g0rm5hr8C6DKmaQhYsCdK15HJcOxShmLScT7VAHw2VoOE= 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 PH8PR12MB6940.namprd12.prod.outlook.com (2603:10b6:510:1bf::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.17; Mon, 12 Feb 2024 17:05:10 +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 17:05:10 +0000 Message-ID: <55623d61-c2e2-49b4-873b-8d1aa78ce142@amd.com> Date: Mon, 12 Feb 2024 17:05:05 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] ethdev: introduce encap hash calculation Content-Language: en-US To: Ori Kam , Dariusz Sosnowski , "cristian.dumitrescu@intel.com" , "andrew.rybchenko@oktetlabs.ru" , "stephen@networkplumber.org" , "NBU-Contact-Thomas Monjalon (EXTERNAL)" Cc: "dev@dpdk.org" , Raslan Darawsheh References: <20240128093943.4461-1-orika@nvidia.com> <20240208090919.11565-1-orika@nvidia.com> <50189a77-2c1f-4b31-935d-506fa98d22af@amd.com> From: Ferruh Yigit 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LNXP265CA0065.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::29) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|PH8PR12MB6940:EE_ X-MS-Office365-Filtering-Correlation-Id: 0181ac36-a48b-42a9-21d4-08dc2becc567 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: txesqNlpc800m7oR/2OMfrJO7i6uEK/Ok37GxOLOLkKRGFVyI8Nu47P/ZhP6OGnEQsn+xu43Eycabo+YAaFl0fjqFmBttI2s/iSuc3CSBkHXnoi82Xwobs/ixEt4vzVFhDI5VZYJ6iKHQVJD+dx9ENbbej1mXeR+dJyUNNIfWlhY45yh/hsTa4JVMi+mjr3N/Qf5bNSlKghIYNor8HtYIras/jacSly6OVUE6bpDZRNqtdL/m312UVoJqqTcUQlFXrovmHrokSUvOHjVguUssFXowbaPWIgWIB4tZ67ZPX8NpVk7W1DJ0oVAyQNxBw4aedeDrpQwugpUzbOs/acezUlok57ZLMrbHqyXVF33jYE6+DGiCCVNznHNyJhC2EDey8yGA2v9PLYUZW1fM2G2AHIUEUt7sSx2xSKWkuQLL2HfWaAUusgYHtnoIfRddTlUYqQfFtKXf9XAEsyOBMtta7hXPU2X9MS1cMsBqI811LKcN6aUpLdBuUvMvXQE/lYHTyBVSMK48l103EdsBR7fnKbIhpFhOJ/nE0maDeb/ZQ42y5ahfxV/au4DejgFCjCk 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)(376002)(346002)(136003)(396003)(39860400002)(366004)(230273577357003)(230922051799003)(186009)(64100799003)(1800799012)(451199024)(31686004)(2616005)(41300700001)(26005)(31696002)(2906002)(4326008)(66946007)(66556008)(44832011)(8936002)(66476007)(8676002)(5660300002)(83380400001)(478600001)(110136005)(54906003)(6666004)(316002)(53546011)(6486002)(6512007)(6506007)(86362001)(38100700002)(36756003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SzhFS2dmakNtZDZOK2NSZjBULzN3RnE1UVp2cU8xamtyMVFkTTg3aEtRU3dr?= =?utf-8?B?ejFZRXc3akFYWmlsTk5kTmdyc3NsODljYVA1U25wUlVrd0UvUWk4dWZkQnlD?= =?utf-8?B?eVdaNkNZc2dzQXUralhkTmJWUlZNZ3JabTVkM2hwRmNRM0wxbjgzbTUwc1kr?= =?utf-8?B?aWJXMEtTNlRjbFRqbzNZSlFXNDFrcmtFMXduMXI2Q2t0SGZYM254eHVBWHE3?= =?utf-8?B?a3Uyc0VCMGZtS1JFbGltT0w0ck9vK3dOUytnejZKWVpETE90VVJheGpXVUwy?= =?utf-8?B?WWtCTDVpRzVZajl0QTRmdTN0ZWJBUUNTbU9iQzBCSkhHaDlPYUlsYVFnNWVE?= =?utf-8?B?d1FxWU90RGloS1p1bjdMRHFkNFozNTBIMUE1U29EZjRBaFJmRVB4TEtpdW1m?= =?utf-8?B?MnBsb0x1VFBLbTUxakJlYnZrM3A1QmptUlN4ZXlZWjlWcWMxdFl6NWZJYVNS?= =?utf-8?B?MVljNkNnbVZXWGxyYWtmU1JVRUZKcm8zTEhpZFpBUER0YklnUWRYSG15NHhM?= =?utf-8?B?cVdkbkNOd3RjbDRka1BUNmpEbzVmdlV2MnhvQ0NqVFF5SW5tY280YlRFUVZt?= =?utf-8?B?WXk0NjFkelA4dXhpaGdRbnJCaFY1TE5EVFNOeS9QRkRUWlBVa1pSNlZHc1NE?= =?utf-8?B?VVpaOUlpdXBCdVFhczdTT1p6ZVJkbXE1ZFpDVmVWc3BLajhqMEU1Wi9PcGoz?= =?utf-8?B?bFArazVEa29kbFVGN1p1YTdER0dDTlkySVhnK1dYVGlTRml2N3Y1WHhmK0Iv?= =?utf-8?B?eloxZ2hVNXkzZ2FlOCtwVXlwUXRMRmdsdjVqaU8ydTVQK1FCS040MXJiaks5?= =?utf-8?B?R2Q2L0FEV2RDZFhZRG1xSHVmTEwzc1VvQTZTZlM0Qko1eWhZQk5sb1ZhaGtP?= =?utf-8?B?bGhrcGZhQTN4L3U3NzR0N1p6VFBHWUs2TDBjd0V4dU1lV0h1ZTliWEJXL2x0?= =?utf-8?B?c0o4SzBGZWlRUVQ1cWdNenVhek1XRUVYcFRBZXhnZmxRWlBVcHhNTHFyYUFl?= =?utf-8?B?dFFqYWQ5YThKbXJpL1BEa1kyemF0U0xZRjV2Q0JybFowZ1hWZEwrbG9PL2xH?= =?utf-8?B?N01ubWZkMkxsZVVBekdaVHFudHNLUi9jT3dpcjh2KzlpQitZb2xaR3FSSFdS?= =?utf-8?B?b2RvR0UwQXN0QXdEUlFpbHdMTG5TODBRSHFlQXR5TGJsL2QwMld6OEtNUEla?= =?utf-8?B?bk92dCtZVktjRlQ0WXo0WWpaRlJkTjlkZ1lOY1lHblBzZ24yb3RGUlJCRmY3?= =?utf-8?B?dW5iS2ZxUm1MeCs3VGVib3NCUnRQS2dGM3BzMDQ4cE5lUzBOc1B2V3B3SlRQ?= =?utf-8?B?VE5KK0tYTzFXTDZPa25mWGlMZUFrcUQvYm9WSzl0VUxrRkt4TmVQeFpRQ1pG?= =?utf-8?B?Q0pFbjBnVmJnbVJPcGhXS2xPZ2x1QXVwUk9ndHk1SWNrNzZoUExCTForSXZM?= =?utf-8?B?RUJGUjFlaFVFbHhxaUlFSWxmaWNGckFZYW80MHdqL3ZCM0FUdGMzbW1zU00r?= =?utf-8?B?YkZMcEoxaWNwUFRDK1FvZWUvYlBNbk5DZ3VCSDVucldHSk5OcWlYZXZHQTdB?= =?utf-8?B?VXl5M2Nhc01ERGR3OHowQWJCc2ovQTZTTVE5Y3o2V0Q5WnVEb0x6Nm5sbCs0?= =?utf-8?B?LzJKdEY3TzYwTEhWQmI4V0Zwa2JlQ240WlozVnJsc2tMelgrYTRKRllUQ08y?= =?utf-8?B?V1FrU3p0czBFUWpub29TUTVGVmgzQTJDZElMTWxrOXg2UUlEb2kzRVhKcWxq?= =?utf-8?B?akFMUE5qUkMzNXFXc0hoakdVWm9EVGtTMzd2NWZzSEFqYnFTNGRackxuQlVJ?= =?utf-8?B?MU9TaG9ZeXQ4WkU5RHhXWHZYME9lQWU1UzFJbWhYc3l2aUU4SnhmMS9oTEtv?= =?utf-8?B?aUtoR1FVTk85UlNNelp3VSs2alFBS25hTFVSditKWDYra3BadUlHaTRHMVJk?= =?utf-8?B?dUpHUnF1NVhrV3l6eHJOeTUxVXFuM25KK3hlNG1CMDhnL3I5QjBUMEt3Z3Rj?= =?utf-8?B?VmVtTVFUcmxtRnROelFtaVFlcmJnNkhzRmpnM1FmR1RiNTYyMm5aYTFDdyt5?= =?utf-8?B?NVg0amxKTG9PQjB4eWc0bXZNK2JBbkVrcTNHMkZCTFN1dUpxMmcrNExLVnJq?= =?utf-8?Q?TQnx8KxIIdzTKgUj2QN+zuN6x?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0181ac36-a48b-42a9-21d4-08dc2becc567 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2024 17:05:10.6159 (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: PtQopes4HDu8Pc05EA2rjoqebnLCCPJDk0rfNFlbXJjBYan56/1wSELySX9JNa1w X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6940 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 On 2/11/2024 7:29 AM, Ori Kam wrote: > Hi Ferruh, > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Thursday, February 8, 2024 7:13 PM >> To: Ori Kam ; 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 >>> Acked-by: Dariusz Sosnowski >>> >> >> <...> >> >>> +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. >>> + 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. 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? >> >> >>> + 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. >>> + 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,'?