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 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 ; 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 , 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> <55623d61-c2e2-49b4-873b-8d1aa78ce142@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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2/12/2024 6:44 PM, Ori Kam wrote: > Hi Ferruh > >> -----Original Message----- >> From: Ferruh Yigit >> 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 >>>> 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. > > 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.)