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 7F6A445AD9; Tue, 8 Oct 2024 00:57:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1954E4027C; Tue, 8 Oct 2024 00:57:06 +0200 (CEST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2067.outbound.protection.outlook.com [40.107.220.67]) by mails.dpdk.org (Postfix) with ESMTP id CC7F3400D7 for ; Tue, 8 Oct 2024 00:57:03 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=deBJGdJ5f7TerWPVK/g8DQt3YOgdecC1aI9QCrS34RkyE4bt+O8peYlY0EcBPQRf0Rz2YbhcdZZscvxnb/uPFss30sdfSIAvkKafjoFi2Ht1sdOhSGho+pfRAkLKs0ZYRPwN0jye8kPCpOJGA1qsQJMGqIuAsQem/z6KxF5gsGkHyBFsOrtzsCC548Czf+MsmQzdFmm7o4RqRCYqJY0DOj22uLDBTzF8V5AXwH2LPosEW+6PYTjq/K0iA/RH8whaV/DMDSGlyJ1QjcCusV6GYaboqN58FKC/hhRqfvLfBaysYLBKLce5pdVWyoicDGYDPqCNphU/drmLoDV+TLhk2w== 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=cuetzjZJZ+A89+aUBpXzr81S/Wk0XKZTSiqG2bZWFco=; b=WfSjOjqgcpKaHxR7j0+DSuuYUW5eNOs0hz8hUhEpscL+/E+8MQq4E9SnTMtiCSpLMjjf4aJ0zywADBz3Ixnmjxvlhf84H1zyKFk1P6i57X3DMfxLCCZ4TPQ0nPGgwYzVqjgRGMNJ89t3wZFH9RLvcFGMq60mjJGZiWAjMKGK4Ja2ur3ZkMvnBNkkN/vaW8KJ7x8WEyiDHXxJfnpR5EBSdbYFMLqPz9IRgFrw7uaeZoxQlsxLUVGrX8ZuvQhQ65FUvSHy6AY6TrgBBz18nxehAciKdcumLElIDxLWHUdpj+wr/vtcdoi+0hoZ5ocz1NMP5q8pPtf5iTCh+xeBDHYHlw== 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=cuetzjZJZ+A89+aUBpXzr81S/Wk0XKZTSiqG2bZWFco=; b=BjHh0gV5rHHhJZ/1VHqKlAO1yIXwZrkkuNcM+4B/KjeBx0qJ1xNNzSWcNMorz1LN1zdbwKXu3Aapbz0GhCq0u+qAZakaVxGHzm+0cwwtYiabJm1b8QeikhUq9G/1J5VvHvKOem6Nb2BXquxt5YlATGTHV74wotviveG9ehjJ7+s= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from SJ2PR12MB8830.namprd12.prod.outlook.com (2603:10b6:a03:4d0::9) by SN7PR12MB8435.namprd12.prod.outlook.com (2603:10b6:806:2e2::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7982.28; Mon, 7 Oct 2024 22:57:00 +0000 Received: from SJ2PR12MB8830.namprd12.prod.outlook.com ([fe80::c3eb:df02:eaa9:2055]) by SJ2PR12MB8830.namprd12.prod.outlook.com ([fe80::c3eb:df02:eaa9:2055%4]) with mapi id 15.20.8026.020; Mon, 7 Oct 2024 22:57:00 +0000 Message-ID: Date: Mon, 7 Oct 2024 23:56:54 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 0/4] ethdev: rework config restore To: Konstantin Ananyev , Dariusz Sosnowski , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Andrew Rybchenko Cc: "dev@dpdk.org" , Bruce Richardson References: <20240918092201.33772-1-dsosnowski@nvidia.com> <13747524-f073-4749-adbd-be1c7681dbcd@amd.com> Content-Language: en-US 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: LO4P123CA0158.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:188::19) To SJ2PR12MB8830.namprd12.prod.outlook.com (2603:10b6:a03:4d0::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR12MB8830:EE_|SN7PR12MB8435:EE_ X-MS-Office365-Filtering-Correlation-Id: c3ae330f-374b-4b45-ebb9-08dce7235a06 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?d1RSTzBVWWJtZC9VRTNXQUZGekxqWC9PS0N5SGhJYmNXSXhxOHRMaGpSMjdO?= =?utf-8?B?VjE4cUMzQ0tpc1BvT0tSUGZwQTBtM1VYemFHeTlGY2FmK2FJTHl1T1BsSDh3?= =?utf-8?B?RThWaDJNRmI5ZmFEMmgxcjFuc3BwVHRJN3RHTFA5WnRueEJSc1dKbHNQSkZD?= =?utf-8?B?NnJMWnJPT2Q4bGNxZUFxOE9pWTJQVDVQNlNDZWRmTU9mMVJhRVFEK01PM2FF?= =?utf-8?B?VURZWDZjenRNSklmdHdJeU1nNUZ1NHpnOGlhd2Y4WERBWHBpTjlpeG1tdktS?= =?utf-8?B?OHAvcDZnM3pTd2NzMUpZNVVFUFM1WjExQndOcnN4VjJaVEV5T0tnWDZQTC9i?= =?utf-8?B?NEtMUXNlWWtqTmxPNlNhRE1ySW1kNU9PNW9USDYwVEhaWTYvT0Y0U2VjZkFt?= =?utf-8?B?MmppRHh3MmhTcmtYbUhlT2lTTWJVTlhnakVwQzBjNUwva0U5QVNhZlVIaS9Z?= =?utf-8?B?WmkxNEFTRk56blpNVld4V0syd0ZObTc0MlUvTkxIU0tNK01NcHd4STcrSW45?= =?utf-8?B?dHV3OTBSL2dobEVIZ0RVbmgwT2FSNVN5VWVsV0tKRmFBZ1RYb2o3c29ZeVFG?= =?utf-8?B?cnd3ai9vUkgxTjZyQms0cWtxRTNJdnVSUFdUSlVlbzJYL2JPdEh1YUdxNkpE?= =?utf-8?B?cU42aDZRWXlWUHFtdUtTWlVYT3c0WHpDK3dDZUhUaDBLOHdSTnFrME43STVo?= =?utf-8?B?WjlyMGhxOWxIZ3c0eGRYbnRSdmdaSkR3djlIZGt2SHFiU1hJTjVVMDljWHlJ?= =?utf-8?B?K01PRUZLOEw2VExZYTNHSHZFNHIxc2w1eStzb0d6cUV1TmJ2RzdVZ0tUeU5y?= =?utf-8?B?cWU2UlVScXFEemZxZzkxYnZUQlJqYTFJZDRMMC9VNXc2MDZveVo1b1c3Qllw?= =?utf-8?B?S2F1Z3hkS0tvaWErWFpuNjNRcFlTVkttbkFjbGtqbm4zU2cyb01VZGJWTEIw?= =?utf-8?B?d3hjOW50dzhBZkVZWDFxVUxLSGR3cDRISGZlbWhLSFErSVZNb21BVkw2MzlC?= =?utf-8?B?MFMxcnJWQkVDY2RHUnlIejJqZTBINmF0VFpYNXFUMjJlUWhPNmw3aW9jaGVo?= =?utf-8?B?VGVySlBZbXJIa1V5ZWVINmFUM3VtYTQvaTdxbFU5RWRlMHFUVml5cnJ1aVE0?= =?utf-8?B?S0hyNXREcUFlSGI1NnpyOFZpQndUdTVmZlJEOHhUVnM0OFlkc09YaDkvWFhv?= =?utf-8?B?OENEMG01cXF0OUhOOTVZN1BFQ3VlVG5tNHY5UmphRkV2clhmdHV2T0tOZGpD?= =?utf-8?B?SGtVUkRaVTZUYnlCRS9ybWs0L1ZLeDYvZjZKTE9KUy9FUDM3a0tmRGI0Y0Fk?= =?utf-8?B?Tk1nbTFlQVFsTnM4ZEhXSDJIRTF4T3N2d3ovWlBTZWN0enNkekF1Qnhiem9r?= =?utf-8?B?Y21neFIxNFM2VEZHZ2lzc0FkTFlEQys1bC9jTVo2eENQMVNoSWcvalNEMTNM?= =?utf-8?B?V3RGYUJGaFV1L2NvczBYamJpUFRzbWQ2Z3dYVmpJYjNkSmRWeUlQamNsNU9l?= =?utf-8?B?QWVGNXFMVCtuU0pyblkwR2tXUDdTUTdDZEYzei9pS3FuTXRpTVAwRjZkMnJi?= =?utf-8?B?REdvTlpDOEhLRUFzQ0hmVFdhYytYUmhPVksyNTFUaWNNUzljYU5BZjlIZVls?= =?utf-8?B?cnpRanZnQ1BiZGxnSTc3L2JBSVZ6R0dLRnQyUE52VjFsQTZhU3U5S2NDWUdJ?= =?utf-8?B?amxJeXc1U1IvYWZ0OXAxVW1LOU5xWTVnSU5wcFZNVExhYy9KT2NPOFFRPT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ2PR12MB8830.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(366016); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TjVjbElVNEM0Y2pybVZaamZHV0o4TmtrTUEvSHcvRzZtVks5UWpRNktPM1Bv?= =?utf-8?B?czRsd1ExWHgxWkVGVHYxTnQ4QlQxUW1xUUxhczFhb3VWTDRJV2Zlb0dVMXpm?= =?utf-8?B?ajJRdEo5KzBrOEQrcHpwN0QrSnlUTkh4UVh0N0V0YmVhbElqOUlzSVdZSnJz?= =?utf-8?B?TDZ3NlgrT3hhOVZTZWQ4NStrMDR0U0U1Wm42ODdIZlVockNDcE9hbGZNTzlB?= =?utf-8?B?OHhZT0lmRlJMUWJ2OWtwN0xOZ2N0a0h0MnR1dFRMekdPdVgvWUxZVktVZm52?= =?utf-8?B?YW9WZUJuRW5vUVUxRW5WakFGUDM2T2ZmS1NYV1VCOW1yU1FmU2t3bHdaaENH?= =?utf-8?B?eWxyc3NIYkFoL0xnVmtITVg3NENWRWEvM0drdVhtcFNUdUpkSENzYS80Zy9O?= =?utf-8?B?Zzd5NjdCb2J3UGlTTkRlV29mdzByY2pCRXBQdmlZa09LcVhHNzVoRE1JbXli?= =?utf-8?B?QVZvKzZqY2hHQmdEbDVUVm85dUJvM1doWWxoL0xheGRzU0Z2TWNVTlRlOHor?= =?utf-8?B?TkZhKzVKeWFiSHYwMUZTYVlHeHFhaGIwQy90MjJDNzFxcXNNdzdxLzd6THlY?= =?utf-8?B?bmR6TjZLR25rZUxYclJFMVNjSzgvUm5hY0tEeVBmSkNKbk82Z2F5cjQvTjhi?= =?utf-8?B?ajBEcE1MY0NQRitoWlF0Wm1nNzBFT3hTcXN4S201bTVwcitHT201WElTbnlL?= =?utf-8?B?VzFqcmdJeFlWeVBMUHFoT3RYMmNaUmxCTW5PaTJaTVhiRjUyL2xQektxSXZR?= =?utf-8?B?dmhkQXd6am43S1JtNG1oUE81MzRpOE80SHBIVHZNS01jNmZnY0ZmRFdFaGtR?= =?utf-8?B?RXR0TU9NR3dCRkNmZkI2SGpEcmRVem5keUtQUFlGYmtrQnNNelBmOWtTenRI?= =?utf-8?B?WFM3NDBEQndtWDF3dG5sL0o4Q0VKd3paeEt0Zlp0T29NSm5ZdEE0cDZOZXZU?= =?utf-8?B?c1dZNEVaNERsYi9UUGMzdHRjS2pNTFJZQUszejcvUEJRdlNJVnd5ZVJxZXEy?= =?utf-8?B?c016bEpqdUVFVjE2cjJhRUUzclZCc2s0Mno0bUlteU9uaVpyeVhxREpEM0t3?= =?utf-8?B?b0FtK0w2MWwvNTQ4SjlsanVaTW5iRGlwdkQ3TC9WMFdvcHpYZXFPdFVuZ0Jt?= =?utf-8?B?NjZlN24zMy9uUm10OWpFb2oyOHFxNFpFcFdNT0NXZ2JZOE9OZmN6ZFFvb045?= =?utf-8?B?aDhBM25IaXJJZHplbjRmb01WTjU2bUlncUdFeDV0aVNMcDl0SklxV2c4SXhN?= =?utf-8?B?eTNja2NmbDdIajFuNWt2MHIvNnR1RHp4UmtaUEx6OG9jcmhXTHR3L1d6VThr?= =?utf-8?B?Q1IzMTFJYWpmU1g2aTdld3FnOFJLNC8wU3hXYUIvMm9iaWoybk8zRC9LSVdL?= =?utf-8?B?TzJNVk14UTQ1MjdhNjk0c1VhRnRvVnBlNzBETFQzVVNLdDFuTHJyWThyMHE3?= =?utf-8?B?MkNNdC9Kak9hRmV6WGRjWVNlK0VCQmpUai8rbXIxdEFYcHk1VXQzc1lrRW9C?= =?utf-8?B?NTk4WSszTDMrQUt6QVlIb1VpQ05oSGpNT3YrcDVxYlJ1QXgwVFZHY25UUlhY?= =?utf-8?B?VHJ5cUN5emwwVDZQVXNxMDY4Zkk0V254UnNnKy8zUERIR01LcDEyUHVDS3Bi?= =?utf-8?B?TUVCSHAyd0hsSkRxTkJuR3ZHVWl3S083ejZWcm1SaWRGbU5tU1RQL05JVksx?= =?utf-8?B?WHJNZXNrODNiZ2k0T3FUZC91MDB0a1RISjk2K05PaFdBK2lnQWx5eFRiYWZm?= =?utf-8?B?bGdPRlkrcVlPTjJGbi9XV2RWUWtXSWhGK2lsU280MnhWQ1Jock8vdGMyaWhz?= =?utf-8?B?aVJUOE5VbWRzNnhDVGFKODB5N0t6a0xUMXdTUS9xRkhHWUhub1U0YWR1aEdK?= =?utf-8?B?aXlBT09Gd3l1bkswazYrVUhzMm9ibXlrTmtOMThyZjFrNUpHUHFmVXJKYVZw?= =?utf-8?B?RnJWbWs0TmU0ZzVaZDE2RnhMQ3g1a1lYb1VMQS9vL2FBV1l3c2prVGVvakpF?= =?utf-8?B?bkQ2NURDR1dWSTNPcElObGtwOUVDTW5rOXplNTBsb0trR1g0NVJkMVlFcEJ5?= =?utf-8?B?SUFHeUcrdHFYNWY0U21Hbk50c1o3cFA2K1lXazJhMS9oUVJvcmFrNmpnVmp2?= =?utf-8?Q?ijGNVsccHi1o+TZOXOnmi6JjH?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3ae330f-374b-4b45-ebb9-08dce7235a06 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR12MB8830.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2024 22:57:00.2343 (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: vcqCB3S5F/V8sIsc7et8A5x8aZf5yiKHI3eyufNz3DeLIQX6aYwk/m5342deR+jY X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8435 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 10/7/2024 10:27 AM, Konstantin Ananyev wrote: > > >>> External email: Use caution opening links or attachments >>> >>> >>> On 9/18/2024 10:21 AM, Dariusz Sosnowski wrote: >>>> Hi all, >>>> >>>> We have been working on optimizing the latency of calls to >>>> rte_eth_dev_start(), on ports spawned by mlx5 PMD. Most of the work >>>> requires changes in the implementation of >>>> .dev_start() PMD callback, but I also wanted to start a discussion >>>> regarding configuration restore. >>>> >>>> rte_eth_dev_start() does a few things on top of calling .dev_start() callback: >>>> >>>> - Before calling it: >>>> - eth_dev_mac_restore() - if device supports >>>> RTE_ETH_DEV_NOLIVE_MAC_ADDR; >>>> - After calling it: >>>> - eth_dev_mac_restore() - if device does not support >>> RTE_ETH_DEV_NOLIVE_MAC_ADDR; >>>> - restore promiscuous config >>>> - restore all multicast config >>>> >>>> eth_dev_mac_restore() iterates over all known MAC addresses - stored >>>> in rte_eth_dev_data.mac_addrs array - and calls >>>> .mac_addr_set() and .mac_addr_add() callbacks to apply these MAC addresses. >>>> >>>> Promiscuous config restore checks if promiscuous mode is enabled or >>>> not, and calls .promiscuous_enable() or .promiscuous_disable() callback. >>>> >>>> All multicast config restore checks if all multicast mode is enabled >>>> or not, and calls .allmulticast_enable() or .allmulticast_disable() callback. >>>> >>>> Callbacks are called directly in all of these cases, to bypass the >>>> checks for applying the same configuration, which exist in relevant APIs. >>>> Checks are bypassed to force drivers to reapply the configuration. >>>> >>>> Let's consider what happens in the following sequence of API calls. >>>> >>>> 1. rte_eth_dev_configure() >>>> 2. rte_eth_tx_queue_setup() >>>> 3. rte_eth_rx_queue_setup() >>>> 4. rte_eth_promiscuous_enable() >>>> - Call dev->dev_ops->promiscuous_enable() >>>> - Stores promiscuous state in dev->data->promiscuous 5. >>>> rte_eth_allmulticast_enable() >>>> - Call dev->dev_ops->allmulticast_enable() >>>> - Stores allmulticast state in dev->data->allmulticast 6. >>>> rte_eth_dev_start() >>>> - Call dev->dev_ops->dev_start() >>>> - Call dev->dev_ops->mac_addr_set() - apply default MAC address >>>> - Call dev->dev_ops->promiscuous_enable() >>>> - Call dev->dev_ops->allmulticast_enable() >>>> >>>> Even though all configuration is available in dev->data after step 5, >>>> library forces reapplying this configuration in step 6. >>>> >>>> In mlx5 PMD case all relevant callbacks require communication with the >>>> kernel driver, to configure the device (mlx5 PMD must create/destroy >>>> new kernel flow rules and/or change netdev config). >>>> >>>> mlx5 PMD handles applying all configuration in .dev_start(), so the >>>> following forced callbacks force additional communication with the kernel. The >>> same configuration is applied multiple times. >>>> >>>> As an optimization, mlx5 PMD could check if a given configuration was >>>> applied, but this would duplicate the functionality of the library >>>> (for example rte_eth_promiscuous_enable() does not call the driver if >>>> dev->data->promiscuous is set). >>>> >>>> Question: Since all of the configuration is available before >>>> .dev_start() callback is called, why ethdev library does not expect .dev_start() to >>> take this configuration into account? >>>> In other words, why library has to reapply the configuration? >>>> >>>> I could not find any particular reason why configuration restore >>>> exists as part of the process (it was in the initial DPDK commit). >>>> >>> >>> My assumption is .dev_stop() cause these values reset in some devices, so >>> .dev_start() restores them back. >>> @Bruce or @Konstantin may remember the history. > > Yep, as I remember, at least some Intel PMDs calling hw_reset() ad dec_stop() and > even dev_start() to make sure that HW is in a clean (known) state. > >>> >>> But I agree this is device specific behavior, and can be managed by what device >>> requires. > > Probably yes. > >>> >>>> The patches included in this RFC, propose a mechanism which would help >>>> with managing which drivers rely on forceful configuration restore. >>>> Drivers could advertise if forceful configuration restore is needed >>>> through `RTE_ETH_DEV_*_FORCE_RESTORE` device flag. If this flag is >>>> set, then the driver in question requires ethdev to forcefully restore >>> configuration. >>>> >>> >>> OK to use flag for it, but not sure about using 'dev_info->dev_flags' >>> (RTE_ETH_DEV_*) for this, as this flag is shared with user and this is all dpdk >>> internal. >>> >>> What about to have a dedicated flag for it? We can have a dedicated set of flag >>> values for restore. >> >> Agreed. What do you think about the following? > > Instead of exposing that, can we probably make it transparent to the user > and probably ethdev layer too? > +1 to make it transparent to user, but not sure if we can make it transparent to ethdev layer. Suggested 'internal_flag' in "struct rte_eth_dev_data" can be confusing and open to interpretation what to use it for and by time become source of defect. Instead what do you think to have a separate, dedicated data struct for it? > Might be we can move this restoration code into the new ethdev helper function,(ethdevd_user_config_restore() or so) > that PMD can invoke during its dev_start() if needed? > >> >> #define RTE_ETH_DEV_INTERNAL_PROMISC_FORCE_RESTORE RTE_BIT32(0) >> #define RTE_ETH_DEV_INTERNAL_ALLMULTI_FORCE_RESTORE RTE_BIT32(1) >> #define RTE_ETH_DEV_INTERNAL_MAC_ADDR_FORCE_RESTORE RTE_BIT32(2) >> >> struct rte_eth_dev_data { >> /* snip */ >> >> uint32_t dev_flags; >> >> /** >> * Internal device capabilities, used only by ethdev library. >> * Certain functionalities provided by the library might enabled/disabled, >> * based on driver exposing certain capabilities. >> */ >> uint32_t internal_flags; >> >> /* snip */ >> }; >> >>> Also perhaps we have go into details what needs to be restored after 'stop' and >>> what needs to be restored after 'reset' and use similar mechanism etc... >> >> I think we should look into that. >> Any 'codification' of semantics between drivers and ethdev library is good in my opinion. >> >> At least right now, ethdev does not change any configuration in 'stop' and 'reset' from what I see. >> But that's on library side only. >> >>>> This way, if we would conclude that it makes sense for .dev_start() to >>>> handle all starting configuration aspects, we could track which drivers still rely >>> on configuration restore. >>>> >>>> Dariusz Sosnowski (4): >>>> ethdev: rework config restore >>>> ethdev: omit promiscuous config restore if not required >>>> ethdev: omit all multicast config restore if not required >>>> ethdev: omit MAC address restore if not required >>>> >>>> lib/ethdev/rte_ethdev.c | 39 ++++++++++++++++++++++++++++++++++----- >>>> lib/ethdev/rte_ethdev.h | 18 ++++++++++++++++++ >>>> 2 files changed, 52 insertions(+), 5 deletions(-) >>>> >>>> -- >>>> 2.39.5 >>>> >