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 33BA4456B4; Thu, 25 Jul 2024 12:16:18 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1386240DD7; Thu, 25 Jul 2024 12:16:18 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by mails.dpdk.org (Postfix) with ESMTP id 40CE640648; Thu, 25 Jul 2024 12:16:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1721902576; x=1753438576; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=bt7fdjyq5jACXlA+scY7BAQ8LYZ59/6LwT/Ht/jbuJc=; b=eHnUgSMiuWBHqPa8FUqq22NfEccebuRASLjUecRLUv+Y7lwoH/E4dYk0 lwETVWgCeEaLPtqOMgOGimtfNQuwx/qzMLS+ZSBhos78RoJerXY8O31QO Njxj2EFmzmwUKMTuefPk4fc2aj4mZm7mkNeO1GyYud0324iYSMqk7V+wT B+OlF7tQBe2CahJ4XZsAKZ9B2IDfsPCn1wmIvqpcdPLuxs+TSNtmjzDY6 VHkh1NauDmo4N6HZd8qZiS4aDVi8K8n2R+Wss9vfCqdSM6431IiQebrsk pDNpOHwnM2CHtRRPCnN7msWRqONBSS4a/bdUFT34o/zujWYhhEqAGj+p6 w==; X-CSE-ConnectionGUID: W9bIxCebQVW+ZCPVtyM7JQ== X-CSE-MsgGUID: SHzSai1eTPCoC2AAB5LEEg== X-IronPort-AV: E=McAfee;i="6700,10204,11143"; a="30775674" X-IronPort-AV: E=Sophos;i="6.09,235,1716274800"; d="scan'208";a="30775674" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2024 03:16:15 -0700 X-CSE-ConnectionGUID: Elbx4danT7mNDMSxlC4oXQ== X-CSE-MsgGUID: 64hemBrRSROQqDfpZ3xe7A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,235,1716274800"; d="scan'208";a="53498344" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orviesa007.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 25 Jul 2024 03:16:14 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 25 Jul 2024 03:16:14 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 25 Jul 2024 03:16:13 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Thu, 25 Jul 2024 03:16:13 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 25 Jul 2024 03:16:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LBDMxHPAPJhHSzVT98wPTURAqZMzO6awJTWAHRmrCxo9cocb2n+yu30YnJdC+qkt1u6SraGaasQHtok0PKBX7U5fF6YJMK9j0m4vBxzWpa6KqDZsfzBcKuArxfvknZScSoISmHilz7VXsojLdtf+TyhkWYp+TsLx9Ym1F36ysqG0D+/Yv9fwZMB1DNWyWCspoefO3T4XAfFHJnFU9lCcljp6L/mRJz6AP3Oq9ZNCVbFwbzxLn6Mlzr1TvPyBcHWepE3qn3REjd3v912nIL0pt3sGj2uNSCpdoGpq7c5Apm5WagHhctXXFCMiq0XLkQmCEATxoy3N52IgBCUR2Y6JAg== 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=Q1n8CV4pG1GgUGnBPQZky5ehpUao6ay4hsn2es6ipfQ=; b=xm6XhI8LYYEHkIpLQLh3rgftdweKeioQ7ejhFYqO8aHBkHs4YQ5jPdycQfTr68Nqc8FTgIeS0V9RNP19JxLtWFgnDGqfnASyUeSEM1Lti/jMKfl80P23b3WVc5W0aO5LdvybsMjOSlom52X9JAwSbBdJ8aEZ8W23pFXzhE0K7yzlkw92O/5dew0Jg00PgjT65dqqRv608SGlUaGbsByqUyk1uJu2p6E3C8Is7xSppaTnzGQ8NX8Kq7igBKG2st5xfnj8DPhK0uqJJsBj90pawVqijXbTgKksZeNiFozP/TvBGG7r7Gw2sDKD4WvOShxcFYMJKehKVX4N6NdebLQO8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DM8PR11MB5653.namprd11.prod.outlook.com (2603:10b6:8:25::8) by PH7PR11MB7719.namprd11.prod.outlook.com (2603:10b6:510:2b4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.28; Thu, 25 Jul 2024 10:16:11 +0000 Received: from DM8PR11MB5653.namprd11.prod.outlook.com ([fe80::2962:1efd:f912:a5a3]) by DM8PR11MB5653.namprd11.prod.outlook.com ([fe80::2962:1efd:f912:a5a3%5]) with mapi id 15.20.7784.020; Thu, 25 Jul 2024 10:16:11 +0000 Message-ID: <3a675000-b050-4a92-baa2-9a704c889d4e@intel.com> Date: Thu, 25 Jul 2024 11:16:05 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix SA salt endianness problem To: Akhil Goyal , "Medvedkin, Vladimir" , Chaoyong He , "dev@dpdk.org" , Anoob Joseph , "Nithin Kumar Dabilpuram" , Gagandeep Singh , Kai Ji , Brian Dooley , Jack Bond-Preston , "pablo.de.lara.guarch@intel.com" , "hemant.agrawal@nxp.com" , "suanmingm@nvidia.com" CC: "oss-drivers@corigine.com" , Shihong Wang , "stable@dpdk.org" References: <20240311024939.2523778-2-chaoyong.he@corigine.com> <20240314020052.3107549-1-chaoyong.he@corigine.com> <7c690dcb-8824-452e-85d5-7f665ff56246@intel.com> <4494141c-268a-4b41-8582-37ca96ddaf0a@intel.com> <7d006696-9a40-4c23-824d-1e984743632a@intel.com> Content-Language: en-US From: Radu Nicolau In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB8PR06CA0037.eurprd06.prod.outlook.com (2603:10a6:10:120::11) To DM8PR11MB5653.namprd11.prod.outlook.com (2603:10b6:8:25::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM8PR11MB5653:EE_|PH7PR11MB7719:EE_ X-MS-Office365-Filtering-Correlation-Id: 083cbc17-a735-47ca-e09c-08dcac92ce59 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|366016|7416014|376014|1800799024|921020; X-Microsoft-Antispam-Message-Info: =?utf-8?B?VVh0cUNLQnVTQUw0aGRGTUV3a0lqVDcvMXR2T1g5QnJmNVl3YWtCZ1dReHhC?= =?utf-8?B?bHlXaTdYUUxhR2FxL0R6Y0FjcU10ellHc0NmVTJHRnUvTzM2UmZlUlpKckNG?= =?utf-8?B?cDBIZW43eG9PWU5tdlV4OVBDMitrR21xaGhMMy81WDAzOWJKeTVYMEVtZnZY?= =?utf-8?B?YVJHeXpRL0FaRTFQVDYwV1crWTlxMVd6dXlqdjBUajQ2QnZhSzc2NDNPT0Nm?= =?utf-8?B?N1drNEJjUjBxOG9oaXpENGIxS2NGM29lWjhPcHNCS1hIaGkwa2x0NGVXRTVx?= =?utf-8?B?NXd4U0dpbi9odm94ckJsci9vTXRGNjByY0xZTy9VYTVvWU1LOWxVWjV3d2ZO?= =?utf-8?B?RWlyWDZuWUFkSWt6a1BOZTg5eUFTdWhwR2JjVmJkZzJ1dnVnaXhRZFdMT29I?= =?utf-8?B?S0VTRlp0MEZGN1p4QjJ3WFRxbk9OUlpjN1Q0RjNIVS9udGlYMXdJUzNqczhK?= =?utf-8?B?Rkw0Q0FlaEEyb1YramhVN2dXM3ZJNmoyQVRjeG4rYjY0cjhnRHpndnJrWjdr?= =?utf-8?B?czN1dUtITlhaZU5CRTNzRkFuQ09Xd3NkdzlXd3dHdFJSOG1xVHBQRGlQcElw?= =?utf-8?B?UUNvbUdLY01NcU1Xb045dDF6K1g0MWN4dzZhNUdoOFdTZHRHYXJXYW9wWWNv?= =?utf-8?B?cXhCYndFbkVRU0EwR05VYlRsTDJhM1MzSUlId0J3UVFmS2hxY2poWk1ESmJy?= =?utf-8?B?bDk5UlpnRStHQ283NUdZenBCc29maXArTzNzam9ObEpmWktENzJ4ZGRPUHJh?= =?utf-8?B?REJZR3ErcEFsTkdWYk5uMFV3bTVDYmd0M2Ewazg1dDlNeWF5Y0lBQzFPWGYw?= =?utf-8?B?alk2N2xvRVhKeHZSZUFLY0lJZTh6YTRCUVpFdGhjYS90RzFoN3AzenJ6ZWs1?= =?utf-8?B?L283WEwvZnFrbnlXR0hYRG5WbVh1SElWUTUrMEZkYzAvVW5PcFhwYlo4K3hj?= =?utf-8?B?TEk2UXRhNWZwZEgwRnhJWmJ1NVR3Z3BXR2lMcjVCeE1hMVJiQjhHdlNBNk5N?= =?utf-8?B?bE5IZnBTckhnTjUxc2JzL2EzdlYwVEpQakFaV09EQ2Rjakd4VURzT0hTRjhJ?= =?utf-8?B?aVg1QytPQmd0ZktVWW1GdVp6amhKQkpBNklLZ0x5THpVVGtKTHUzcFVzNEd0?= =?utf-8?B?a0M5UkFPclp2ekhiaVpHeUdDOTVIbEFjT0xrYmFGS2ZuUjVob21TcHF2M3ox?= =?utf-8?B?Mm9meVk0UWdwbHMvY3JOUW10WTZiL0ZjMDRCL2dUSVdRZlZsdUkxK2NYcGJo?= =?utf-8?B?WGVrdzZaTDhrbmh1S0lEWFA1M0ZjOXVmdnl1a2hhZVpCUjNBc3J1SFhKRGc2?= =?utf-8?B?Q2hTNEtXZEFqRE1PVW4vaDdxWWdwTDdUNEhKbnZUakdGLzBiV1hJTFRGd3V0?= =?utf-8?B?bk9OOWZuekZUYkxpQzcvRk1IZzNKcFBHQlI0QTJ6Q3Fpa1p0bm45QWovTzQ3?= =?utf-8?B?ajhNSFI0ME9yK1VPTDh1TERGcDh4eGlOQUhCc2Y5QVBsb2VYM3ZpdDJ5WUdF?= =?utf-8?B?Tml6a3NSM1ZNUDB4c2dFL1JsTEJPZHREQ0U3MGg0cEYrNTJFbDRuNTRqVUx6?= =?utf-8?B?bytEVURaZ2FaMThmOENiR3BFak9lN05rREpTbE5yckFxaFc2SVY4bWJ5K0Vv?= =?utf-8?B?SjVKMVdxSmxCNk8xSFV6N0VhUmZwNlI5TENRelY3SHByOUpGSzM0OFhJZ1Nw?= =?utf-8?B?c01NZ2hHYTdWUU15YjNVb28ySnlZTTlFOE5KekU3YjRDd2VtdldUa0hrd29K?= =?utf-8?B?enUyREh4WXFNNWRlSG5vMnN0Y1pqQmJrS3lBdldFRitDS3UydFZoU014R016?= =?utf-8?B?K1piRVo2VWNiZjlNanpTVmNXWmdnTHdrV0NvK1NOUjRFd0hDK0YxdUlrbGEy?= =?utf-8?Q?Gz82cwXgXjfvS?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR11MB5653.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(7416014)(376014)(1800799024)(921020); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dEZDelFzYXpMblZqNnpET2JTRThMNlVhYkN4c2xXWkVDM0RHYkU5RWdFamJw?= =?utf-8?B?b3FMYjc4YzdwTG5wMFZWTnBUcGdKbE80Ky9aK0luVUFqR1F5NVNpcEhrNldu?= =?utf-8?B?ZVpuMzZyek1BSkZBN2tQelpWTXRUdjlWZENDSTIycFYyWG1vbitDSFhvcCtr?= =?utf-8?B?ZGgrME1MN2JWR21FSURkTUdxdG55d1REYzIwRXZRaVZBaGZMQjU3dURTY1I1?= =?utf-8?B?cGtRc251VHQzcDdza2Jhclh0RUwrOExXMTROZWZqNXB1SXphbTVGdnM2QjZQ?= =?utf-8?B?U1M3TjI2cU1UMC9NMTBXQWNubjhoaVk0TWVCK3dHR1UyOEFLYldUaWRxY1BX?= =?utf-8?B?NitxZTV1VmJ3dlhJSmg5clU0dmk1RytIa2ljaDJqc1cyV3pQNnFraHlrOWR6?= =?utf-8?B?bU1pSURWT2h3TUZraW1KQ3RralZadE85bGN5aFlNYkN3OHQyOEZvWFFQSkN4?= =?utf-8?B?bm1SNXBpUHlkS0t2MTRBemgwOEI1QndFTnFtYUoxakVDVE9SUnRrcTJhWTRL?= =?utf-8?B?RHFxVmhWTTk2TWN3VmhMTGYwM2Rsc0M2VExucXVaMlZnVFdSZnFFbW9WSy9u?= =?utf-8?B?YkFIZVp6UlFqTzA4SVB3alBGdmhBTGJvd2hzY1d2MFJlVWIzWTVKaGhOZU5X?= =?utf-8?B?TXlyTDZ0UE9VaVMwSGZjRnY1YkJLU3VSKzF1aE5ZMnZnTXNrYUFvOVErMlBK?= =?utf-8?B?a2M3YTlwR0hBaEJwMG5HYTRoZm0yUXdXeTJzRktXSW5XMVFiNUFLZTd4RXgy?= =?utf-8?B?bHpmKzJnMGRaNGE5bGw3aFRGOWhHWVRHSWtuTVJBRzRzQUsvb1ByYUxhdDFz?= =?utf-8?B?Y1ZobHhxekkvK1VOQ3dpTFNjVEwzVklnSVN3ZXZlc3o1K1orOE9XWWUyUXhK?= =?utf-8?B?NVh5WnFXSDgwbUFVUnV3bDg3ekltQ0RLblJnbGhTL3BWWE94R1UwVXNiV0pp?= =?utf-8?B?S0RkMk1Hb0x4Ymx6RVA4b04vRXIwd2U2bmxERXlrOGVjNlh4MVRWSnJ5SUtR?= =?utf-8?B?cVEvN3ZxMGJEMzdwSHhzMExVRmpwUFhlcWtSK2dRMFNic3hFazNvNXZrdmtk?= =?utf-8?B?aUxPTGJKRmlYSjJwYzRVQzJiblNnMlY2dnhkRUo0SG5uYzQ2QWJabGhmckVk?= =?utf-8?B?ekh5WkRZTGRJbXRWdzYwVWlLM3BKRDlkVEVaNHdaS2syU2RJWTVYOUV4eW1S?= =?utf-8?B?NEh1dGhDS1owMEQ4eDgzTGhJMmtxYlh5Sm50akE4K0UrRjNJU0pmOFZKNUZa?= =?utf-8?B?a3NkRTRVQTVqTFMwSkYrWmZzYXhqdlJFUFVIbHVaOG1pSVNtRVBzMW1IZjMr?= =?utf-8?B?dHJ2Z3FvZmVGZGQzcWd5NkF1N2RvZHFxK1VoWGQyb08yRGhoVWtFd3o5SGY5?= =?utf-8?B?eVdDL2xrejVmSzVYUjRRV3B5RVpyQ0dubisyRnZxNWJBR1pCTjUxam4rQU55?= =?utf-8?B?U2hIOHNuOTZWaHVQdTd1TkVsUkcvVHRaczNsUXFibEg1dGFncTdZdGdnUjVJ?= =?utf-8?B?SmhSUHlwN2N2MlZ5NFJIU3pKeVZXU3p1bEdSOXV6TmV5emxFVUprbEExc3ds?= =?utf-8?B?cHlzR2R1TnNuS3NpRUtvcEJpc0cwSWZPcG9ieW9oWkhhVW9HYnVhaFRMMDI5?= =?utf-8?B?SzdiNDZrT3NEVFRDMlhYc1NmNFFBWXdFYktmd2FQWHhuY2NUU3hVczYwMjhY?= =?utf-8?B?TmtjK3hJWWJ2Y2NRM2pGZTRrWUtSVllLN00yTllCWFZmaDZnMlU3T1JCYWdM?= =?utf-8?B?YU83NURMcXFFWWlUaVdKRzcraU1SSEdnSnpHWEE1bFQ0NWs2ZnhTRE9ZZDdS?= =?utf-8?B?YmhIYXhHNkRQcGRzNzBJUkJFMGRudW5oRUNaVGxyWVhaRG1wR1hCR0NXeFhG?= =?utf-8?B?d1VRbWJLV0o3NDdoYS9SRGZySER6anFTWHZscFk0RWQ3b0JMWFhxQk1rUEV0?= =?utf-8?B?QUw4Mk1FZm1SVk9KeUR5R0xvcEVwcnUyWklXcXhCazAyUUhHdURGS084REgr?= =?utf-8?B?TDJ2R2phenJRb1N2S3dsOVFtdEJNTXRRbTgwdGJ5NTVLRUsxQjlyODQ0Mm1I?= =?utf-8?B?SGhxd01SSzZ5SHZyR1B6MngyQTZTV1daYW5aMncvUXgrb1NrTVlHWEhPU1dI?= =?utf-8?B?LzFyK2xRRmk0NDVvZzl4L2VQZlZ6NFpEQUdpQTNZaGhxMGcwcnVSdHBFS0Fw?= =?utf-8?B?T1E9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 083cbc17-a735-47ca-e09c-08dcac92ce59 X-MS-Exchange-CrossTenant-AuthSource: DM8PR11MB5653.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jul 2024 10:16:10.9462 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: V406iru8hAY74vRPmAVYgI5xQUyA9K0r77Vvu3Pm/RyeypQNhVxsys5xZpLWlPDq9u4xG1weuQzOreZqAxCbtA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB7719 X-OriginatorOrg: intel.com 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 25-Jul-24 5:47 AM, Akhil Goyal wrote: >> On 24-Jul-24 2:04 PM, Akhil Goyal wrote: >>>> On 24-Jul-24 12:20 PM, Akhil Goyal wrote: >>>>>> On 23-Jul-24 5:57 PM, Akhil Goyal wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> This patch breaks ipsec tests with ipsec-secgw: >>>>>>>> >>>>>>>> >>>>>>>> ./examples/ipsec-secgw/test/run_test.sh -4 trs_aesctr_sha1 >>>>>>>> ... >>>>>>>> ERROR: ./examples/ipsec-secgw/test/linux_test.sh failed for >>>>>> dst=192.168.31.14, >>>>>>>> sz=1 >>>>>>>> test IPv4 trs_aesctr_sha1 finished with status 1 >>>>>>>> ERROR test trs_aesctr_sha1 FAILED >>>>>>>> >>>>>>> The patch seems to be correct. >>>>>>> Please check endianness in the PMD you are testing. >>>>>> In my opinion salt should not be affected by endianness and it should be >>>>>> used as it is in the key parameter. I think the patch is wrong to make >>>>>> it CPU endianness dependent before being passed to the PMDs, any PMD >>>>>> that needs the endianness swapped should do it in the PMD code. Indeed >>>>>> it's passed around as a 32 bit integer but it's not used as such, and >>>>>> when it's actually used it should be evaluated as a byte array. >>>>>> >>>>> As per the rfc, it should be treated as byte order(i.e. big endian). >>>>> But here the problem is we treat it as uint32_t which makes it CPU endian >>>> when stored in ipsec_sa struct. >>>>> The keys are stored as an array of uint8_t, so keys are stored in byte >> order(Big >>>> endian). >>>>> So either we save salt as "uint8_t salt[4]" or do a conversion of cpu_to_be >>>>> So that when it is stored in PMD/HW, and we convert it from uint32_t to >> uint_8 >>>> *, there wont be issue. >>>> >>>> RFC treats it as a "four octet value" - there is no endianness until >>>> it's treated like an integer, which it never is. Even if it code it's >>>> being stored and passed as an unsigned 32bit integer it is never >>>> evaluated as such so its endianness doesn't matter. >>> The endianness matters the moment it is stored as uint32_t in ipsec_sa >>> It means the value is stored in CPU endianness in that integer unless it is >> specified. >> >> What matters is that the four byte value in the key ends up in the >> memory in the same order, and that was always the case before the patch, >> regardless of the endianness of the CPU because load and store >> operations are not affected by endianness. With the patch the same four >> bytes from the configuration file will be stored differently in memory >> depending on the CPU. There is no need to fix the endianness of the >> salt, just as there is no need to fix the byte order of the key itself. >> > When a uint32 is used, there is no clarity whether it is in BE or LE. > So that is where the confusion comes. > For any new person, uint32 means it is in CPU byte order. > This patch tried to address that but it failed to address all the cases. > So my simple suggestion is instead of fixing the byte order at every place, > Lets just change the ipsec_sa->salt as rte_be32_t from uint32_t and revert this patch. > This will make things clear. > I am suggesting to convert this uint32_t to rte_be32_t for library as well for salt. > This change is not swapping anything, but making things explicitly clear that salt is in BE. I agree with the suggestion of using rte_be32_t and reverting the patch. (I still think it would be even better to use uint8_t[4] to reflect that it is a four byte value with no endianness but that's just IMHO, the important thing is to revert the patch that broke the functionality) > >>> Now looking at the code again, I see the patch is incomplete for the case of >> lookaside crypto >>> Where the salt is copied as cnt_blk in the mbuf priv without conversion. >>> >>> So, this patch can be reverted and a simple fix can be added to mark ipsec_sa-> >> salt as rte_be32_t >>> diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h >>> index a83fd2283b..1fe6b97168 100644 >>> --- a/examples/ipsec-secgw/ipsec.h >>> +++ b/examples/ipsec-secgw/ipsec.h >>> @@ -117,7 +117,7 @@ struct __rte_cache_aligned ipsec_sa { >>> uint32_t spi; >>> struct cdev_qp *cqp[RTE_MAX_LCORE]; >>> uint64_t seq; >>> - uint32_t salt; >>> + rte_be32_t salt; >>> uint32_t fallback_sessions; >>> enum rte_crypto_cipher_algorithm cipher_algo; >>> enum rte_crypto_auth_algorithm auth_algo; >>> >>> Can you verify and send the patch? >>> And this may be updated in cryptodev and security lib as well in next release. >>> >>> >>>> I agree that we should have it everywhere as "uint8_t salt[4]" but that >>>> implies API changes and it doesn't change how the bytes are stored, so >>>> the patch will still be wrong. >>>> >>>> >>>>>>>> On 03/07/2024 18:58, Akhil Goyal wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Akhil Goyal >>>>>>>> >>>>>>>> Sent: Friday, March 15, 2024 12:42 AM >>>>>>>> To: Akhil Goyal >>>>>>>> ; Chaoyong He >>>>>>>> >>>>>>>> ; dev@dpdk.org >>>> >>>>>>>> Cc: oss-drivers@corigine.com >>>>>>> drivers@corigine.com> ; Shihong Wang >>>>>>>> ; >>>>>>>> stable@dpdk.org >>>>>>>> Subject: RE: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix >>>>>>>> SA salt >>>>>>>> endianness problem >>>>>>>> >>>>>>>> >>>>>>>> Subject: RE: [EXTERNAL] [PATCH v2] examples/ipsec- >>>>>>>> secgw: fix SA salt >>>>>>>> endianness problem >>>>>>>> >>>>>>>> >>>>>>>> From: Shihong Wang >>>>>>>> >>>>>>>> >>>>>>>> The SA salt of struct ipsec_sa is a CPU-endian >>>>>>>> u32 variable, but it’s >>>>>>>> value is stored in an array of encryption or >>>>>>>> authentication keys >>>>>>>> according to big-endian. So it maybe need to >>>>>>>> convert the endianness >>>>>>>> order to ensure that the value assigned to the >>>>>>>> SA salt is CPU-endian. >>>>>>>> >>>>>>>> Fixes: 50d75cae2a2c ("examples/ipsec-secgw: >>>>>>>> initialize SA salt") >>>>>>>> Fixes: 9413c3901f31 ("examples/ipsec-secgw: >>>>>>>> support additional algorithms") >>>>>>>> Fixes: 501e9c226adf ("examples/ipsec-secgw: >>>>>>>> add AEAD parameters") >>>>>>>> Cc: stable@dpdk.org >>>>>>>> >>>>>>>> Signed-off-by: Shihong Wang >>>>>>>> >>>>>>>> Reviewed-by: Chaoyong He >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Acked-by: Akhil Goyal >>>>>>>> >>>>>>>> >>>>>>>> Applied to dpdk-next-crypto >>>>>>>> >>>>>>>> >>>>>>>> The patch is pulled back from dpdk-next-crypto. >>>>>>>> This change may cause all the PMDs to fail these cases. >>>>>>>> Would need acks from PMDs. >>>>>>>> >>>>>>>> >>>>>>>> Applied to dpdk-next-crypto >>>>>>>> No update from PMD owners. >>>>>>>> Applying it before RC2 so that we have time for fixes if needed. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> Vladimir