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 6A41A45B08; Thu, 10 Oct 2024 19:08:40 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 33BE1402A3; Thu, 10 Oct 2024 19:08:40 +0200 (CEST) Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam04on2075.outbound.protection.outlook.com [40.107.100.75]) by mails.dpdk.org (Postfix) with ESMTP id 2839140144 for ; Thu, 10 Oct 2024 19:08:38 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BxD66KgZJ8TD1HYuF5bpsRoUXNrXRyyhFH+hqftC2M/Zq9335G+ySrlegfkFswJo5iXBfct502ZHsJ1WQex0YyxlzZqd81ACjY9lUKVEB5wNgH+8yp1yADaW+C/djVJmHRIHifZZ9OuHJSZQSZLZ3pqcSFhFVfeWDaYQMlcsUzNpCR1jE02XTbJiPfoltn4BE9pWYvfL2MLOtUVIe2zD37Z886v/JhfV2n3IyjeDfl9v8LGkfhHFftno6frkrOBBcU6QIwDh3LlVzyHsr0g/hTsdpopp1PCYu04pZWN2FypymYXfctEuKXR1H5IFH1FUa1RSlpDi0BrHOyz4aKQ6qw== 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=haT4nS0q1RdvgOuyb4URiyOtFKldghCsDHZw9sAIZBw=; b=VUAPZ6yKPXDGkGJAVFfoAOzM2Ttjw2k4ahN63he+nwyTlXIhqtVrcs7RgN6+Ad5XGgTuNKnI9Nhj2PrcoJ/ln2GmrL19yiqk0k367DGSjtE4QJyUOKONDwvhXlKOKLL7vSctEHClYhMPeMfqRERzflt4fNLpNqF9OEsDx01z3zWAEfQiSE8DLovPfeXMqk4IeNmNGL7BKI1PKSJvaaN42tULSjkLv8DzGXQQJ+yTfDPynNEnOpaY8U+9ocVMNq7LcqgWifw6TvRsxxLAmGykF5ETeOJA8vLfH/OaZw7CqFpg1hWFX6Id2rsoYOKpZvXP3yeS6HsJh6r5tgtDLPS7Mw== 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=haT4nS0q1RdvgOuyb4URiyOtFKldghCsDHZw9sAIZBw=; b=nYUphWqmxaUdxr0pfQrZI0coyNRVES53wiliFrrQxOzMq8altpW0cqbc0fRJ2+JNjrFXDdiL5q/vbWwfwr8WnXjbJ+qg7mAeGESn5/rwuwVfNRhD9DCnAgouRVN5dKsP0nQZStJgH1mD6hp8yXa8jBJH3iQL0vLhnyNvo/0KdlI= 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 SN7PR12MB7810.namprd12.prod.outlook.com (2603:10b6:806:34c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8026.24; Thu, 10 Oct 2024 17:08:35 +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; Thu, 10 Oct 2024 17:08:35 +0000 Message-ID: <6e2487af-5bf5-4a07-bc9d-2e6f1a1def19@amd.com> Date: Thu, 10 Oct 2024 18:08:27 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 0/4] ethdev: rework config restore To: Dariusz Sosnowski , Konstantin Ananyev , "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> <3833d9270fba43af9d17765056911940@huawei.com> <8a6f760c-8bc7-46cd-92e0-a8af66114e2d@amd.com> <5ef19db7-f6fe-4a48-8497-e17b33a262b5@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: LO2P265CA0112.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::28) To SJ2PR12MB8830.namprd12.prod.outlook.com (2603:10b6:a03:4d0::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR12MB8830:EE_|SN7PR12MB7810:EE_ X-MS-Office365-Filtering-Correlation-Id: 0c4eb19f-7c36-4bf6-e49a-08dce94e2cb4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YXVHS09zYURiTE9RdHl1RllWc0djMkErOHRzMWRBK3hZTEZ4cG52RmJLL2RV?= =?utf-8?B?aWhhNWZBaUpmc1VyaG1wNXl5RUlkbU9yK21iRWN4a3BRRlNzdG5hWDRxUWI0?= =?utf-8?B?OUVOSk1CeDlFNFE5RGZhSTlxeTBQT2hmK1Zmcjlkb2k3N2RTSWtUTW9xVG1k?= =?utf-8?B?eVI4c3Z4Z05Tdmp0V2VuREJjNElnMVpRSjl1bkt3ZDlRRDNHNUt0TUJGOU5N?= =?utf-8?B?VWY0MWN2Tmw0NUFuOTRRNkVDcGNUV0ZpQkxzQjZTdGkrZTlXR3htVHZrQUhN?= =?utf-8?B?SlIwd3RNd0FRbG5tc1dnN0NtUXVLWFNOUC9icmtMVCtjTm52NTU5Q0QwVnRD?= =?utf-8?B?QWN2UDV3dHgvcEZtMEJ1VXBxSThaMlZ3SEVyc09rb1pPRytIZmM4ODY2QzNw?= =?utf-8?B?WHlsd0dUam1oamJYc1JJckV0MDNiN3B4NGlySHJyWHBpRTlVKzMzcEZCeGxs?= =?utf-8?B?QUdOSWx0ZTMzaEx4bnlhQzlJcG1yenNNaEgySkRYblR4VVRsZTNxQTNTUUZB?= =?utf-8?B?di9JdXJDU3N0b2RBT1NHN0VJRUpCYmR6eVBpOG9MVDlmTkpzVExPd2FlaVl5?= =?utf-8?B?VlRVSm5BU01nVWZIeXBEbUpWZmJtaysxa2dxWllJVE9lLzJSTGZhQng1OHNi?= =?utf-8?B?amFlOWc2eThSN1lUT1NITGtJMHJkMmc1d05weXdtSUJ5dmRmZVlKVzAySmdt?= =?utf-8?B?MmMxRzJ5RmM2cGthSitHMG1rZDV2em0zWWpaK0NISkFtTUNPRmpDdXMrY29r?= =?utf-8?B?R2tUM2k0YWRzUWlsZkpTcVF1aWxySkNwNUpzaDA5MWp1S3VoVVlybHozS3pK?= =?utf-8?B?S0orT3VpSDZKUVhETVBPK0xleURucWt5OTRhZEc5Y2RQMzFyZ3F6WFpxU3FM?= =?utf-8?B?ZGVHWks2NTBBSFFXU25abDNJeUdNZDR4RmxDaGVGaVNYVlE1amxzSE1QL2Zr?= =?utf-8?B?eW5EVStwVGZvdjQ3ckdvQzhZSnNkZW1wMlN5aHhMRklaRVJtQVFYU3Axejgx?= =?utf-8?B?Q0gyZ0NWTnplMEtCdmxpOXZxaG8wRmE5VU1hVWg5M3F1QkRhZjFYQ2VvRCtt?= =?utf-8?B?eFBEazNVazhkVmVSSHJkd1JxLzZJNlpxRTF5M3pKWmI4aEcveVpKMlBYak5H?= =?utf-8?B?TW9XQnBtVklUQ1Zyckk2NmdNOHFXSnZ1ZUY2MFp3c3RVeVU0WkpaZktkUDN3?= =?utf-8?B?QWgwSTR1ZXEzeldSbHVINmwrMlZvRXdydUJoUWJwVDN1R0NKWW5YWG5wTmxP?= =?utf-8?B?ekhvZHZwR29TczVaTHd6eXFWRHNHQTUzNW9oUHJWU0poQlNEV002N01XcGJ5?= =?utf-8?B?L1dBbkl4K1Aya3VYVXlwdmg4dUlCdjN5NDEwbzFKSHBBakNwTWQ4YlFXUml5?= =?utf-8?B?SmxuNk92TitwM244SUxEdDlmOG0rMHRrcklJM0xTbkI0MVErcERMcVlJQXRK?= =?utf-8?B?elNUMFl6Zk93RHBXazFXSGtrNGpibWNpSlZiSFlySlU2S0VUVWVEdEZZcVF0?= =?utf-8?B?aEEwdWpLU09TUHZGMDB3b1hRODlGbVA3dU5kTWRvb1UvN0k5WWhvUnF0QTJ4?= =?utf-8?B?SGVLeTA1WU1hN0FCU1FFOEdSclA5NXVYOU1VY0tyc2tjVUVnWndRK2Z0RUFn?= =?utf-8?B?MXFOOU9JSk5lajY2dHN1alN2WGp6S0UrNXNMcTBHQkwvKzJmaFYvSzYyWS9Q?= =?utf-8?B?L2s2Q1JKa3hwVnN5aG5OMkJCTWV3WXBxZm1ZY01iU2tESGxWTW9Sb2dBPT0=?= 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)(1800799024)(376014)(366016); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SkxTNThZMVBCR002TDQ3QkY1alJoNW5LV1RXMW5nV3lQeXJlMXdYb2Rzam04?= =?utf-8?B?Y0NFWk45RjN4WVFKMGNPaC9QT3REaDB5VEQzazVqVVljQS9ZN3JYSlJzQUQ1?= =?utf-8?B?OVFLUXQ0WXh5anU3R2o0WU51TGR4RkE2VU1zTUR4eDY3amVpZ3RNa3p2M2Fw?= =?utf-8?B?eUgvVVlINVVxYzN0TXdQamkwMFd6eVdTL2VBS2pRUURPYjc5c3NLODV6QWpO?= =?utf-8?B?aldMQTJTd05LRzYwbDc1RUJacnY5U2NjMGtVMFF2VVR5T2dGUW44ZEc3ZWRZ?= =?utf-8?B?NUVMeDlJUHJKK25SeDUwVlA2cGt4Z3hjTGVtc1pGS1p3Q1ZjMWdQUUx0RC82?= =?utf-8?B?dnVZT3dxT2U5WEk4K1RzTCtaVmlweUxxV0xYYTFWMGk5SW41SG9QUmNHNUh4?= =?utf-8?B?bHFGQ0M2dlBscm9QVU9QU0VpaTBLRnc1anJ4MVBSaUxGMC80aWhHcWtrRDZs?= =?utf-8?B?d1I4bFE3OXI0djBSaHpSdXNYUDdGU3J6V3d1VllvU3JGWGZtV1ZnclRvSmI5?= =?utf-8?B?R3hOY0Q3bDl4UGhiaC9yQ0xTbGwwVFpkVytsRFpEcFkxOFdCS1N3WWdFMXNr?= =?utf-8?B?a3VuS1JCT0lDRVNmNTlud0NQOHJzMGY2b1JVcitHdG1mcDVPbEFtWFdqK3BD?= =?utf-8?B?T3pMSTZ2a2RPZm9HMmI1eS9YWU5VcWkyT08wS0tHdFc5UmZlY0tzOS9RT2Nl?= =?utf-8?B?Q2pwN2JVV1hYMW5xV2prbzB2MTJmY1NjU3VHQjNSV3dmaVpZQ3RSVnBXN3B2?= =?utf-8?B?aVRBem1qK0tFdC9CNlNEUkhjTnFRdk1DV3dyMGMwK2dybU9JblZWYS91dE1W?= =?utf-8?B?UnozWU44c0k3ejJNQUxiK3BFN3J5VjU1NDdRRDZma0hLTDNvUlJtRmNxNGtS?= =?utf-8?B?bDlHQlE0OGNqNVFMRDV4MFNHVnNOVDZ1Nll4bUFUVldIYkZGdzV3UWs4Z0FR?= =?utf-8?B?ZXNsR3kyd0xhcXFsSlBPeEQ5Yld2YUg4eXpRZ3ZENzY5SnBlbU5FRFYzbmUv?= =?utf-8?B?Q0ZvaUoxdDVXMUFYU2w5dmlyWnl3a0g3Ykc0TVFLR1o3Ly9wd0JUdWdWRWNz?= =?utf-8?B?V0k0RU5PZEtQTkgzenhXRkpaSjZ5QnZpT2JwY1h0Rnl5ZTAxb0F1dUFpWW9p?= =?utf-8?B?R3hrNjRQU0cybUFnQ0tqSVVNYTQ4TFdCcHpocWl1MFQwdDVreHpPNEl1UFFa?= =?utf-8?B?b0N6dWxpdGgvdFJQSXdOV3BXYzZybVA2ZVkzbXA2TVo3VlJySGI2VG5MV3Ri?= =?utf-8?B?UkJOQ3VPckRTTUw3MVIza3hUdTR5L1BSNzQ3U3V6Z05KMlEwY01sQVE4MUVP?= =?utf-8?B?UzUzbVMvd1FhZXBWUTdOZ1o4TDhKdE04VFdNdFVEUDY1NGROc0I1NUczbFBN?= =?utf-8?B?N2tMZUszdjB4R2NMRWdnZFhSVjllemVpdDh2YlFmWDdKOGdhODJ3bmsrM0lz?= =?utf-8?B?WlZBbHpMclVEaENaSkNuM1Zid3hNM2x3V2NuVi9zb09vR1dVYVk1WnVsZ3JB?= =?utf-8?B?enc2UWl4cndUVFBDNXNBZDU5MVpqNHcwZ1dJOU9yMDBhSkdyMERFQVRtQlZ2?= =?utf-8?B?c0dDUjAxNllDMmM1M3BiOVppckp2S2NXSmNRY2tEbnlkczl3UVQyZGNOcUxV?= =?utf-8?B?bnVzMTEzWFUvb08rbXUwZmgzMmRiRlYxTFB5K1Nickh4SVcvaE4xK2MvOURu?= =?utf-8?B?WXZjT1QrbnFaYkJsbUNuUTZod3FOekxaT0VsWjlhMzQvdTcrSy80WWgyNmQy?= =?utf-8?B?ZUkwYTlsWE5lZGk3MGJpaEVrd3I2eUJmMzZ6L09ObVNsUjF5ZHNXRGUxZ0VO?= =?utf-8?B?ZzhZcHVsTnRsVkE5NllseXkxSVNTcHVrUEtqVGVUVG10UmhKeEhHVDA3Z1JO?= =?utf-8?B?emQyZm0vOWVzTVE1bnl1cDB3eGxaczhnSUdNTFVET0ZsWi8rYkVaNGd3VEpF?= =?utf-8?B?eG5Nb0xudjJIOWJMY3RPMmVVdS9oMU1GemY5d0xzeFNuUG5CbHY2bnAwVnBF?= =?utf-8?B?eHM0c0VxTkdkNGQrUnZGRm1hakgwZkhzTm04Y0gwRFI2MG0wNzBENkRFWkN4?= =?utf-8?B?S1dtQ3dXcU1WYXVvTUw0cjdsc1M2dzJ2ZWlRODNnaFNvTTd5elpEVnR1dkY0?= =?utf-8?Q?D6qSlaohSnMF1maXozJOtDjtl?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c4eb19f-7c36-4bf6-e49a-08dce94e2cb4 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR12MB8830.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2024 17:08:34.9440 (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: eeVHEq2wM+BQQYPIr72DILCwsodWkAQrl0UEpH1yg2LFu6vVhV0wlwts+Bwy8QOC X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7810 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/10/2024 5:23 PM, Dariusz Sosnowski wrote: >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Thursday, October 10, 2024 14:52 >> To: Dariusz Sosnowski ; Konstantin Ananyev >> ; NBU-Contact-Thomas Monjalon (EXTERNAL) >> ; Andrew Rybchenko >> Cc: dev@dpdk.org; Bruce Richardson >> Subject: Re: [RFC 0/4] ethdev: rework config restore >> >> External email: Use caution opening links or attachments >> >> >> On 10/10/2024 1:08 PM, Dariusz Sosnowski wrote: >>>> -----Original Message----- >>>> From: Ferruh Yigit >>>> Sent: Thursday, October 10, 2024 01:17 >>>> To: Dariusz Sosnowski ; Konstantin Ananyev >>>> ; NBU-Contact-Thomas Monjalon >>>> (EXTERNAL) ; Andrew Rybchenko >>>> >>>> Cc: dev@dpdk.org; Bruce Richardson >>>> Subject: Re: [RFC 0/4] ethdev: rework config restore >>>> >>>> External email: Use caution opening links or attachments >>>> >>>> >>>> On 10/9/2024 5:18 PM, Dariusz Sosnowski wrote: >>>>>> -----Original Message----- >>>>>> From: Ferruh Yigit >>>>>> Sent: Wednesday, October 9, 2024 03:08 >>>>>> To: Konstantin Ananyev ; Dariusz >>>>>> Sosnowski ; NBU-Contact-Thomas Monjalon >>>>>> (EXTERNAL) ; Andrew Rybchenko >>>>>> >>>>>> Cc: dev@dpdk.org; Bruce Richardson >>>>>> Subject: Re: [RFC 0/4] ethdev: rework config restore >>>>>> >>>>>> External email: Use caution opening links or attachments >>>>>> >>>>>> >>>>>> On 10/8/2024 6:21 PM, Konstantin Ananyev wrote: >>>>>>> >>>>>>> >>>>>>>>>>>> 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. >>>>>>> >>>>>>> Just to be clear: >>>>>>> Let say, using example from above: >>>>>>> >>>>>>> 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() >>>>>>> >>>>>>> We probably can introduce ethdev internal function (still visible >>>>>>> to >>>>>>> PMDs) that would do last 3 steps: >>>>>>> ethdev_replay_user_conf(...) >>>>>>> - Call dev->dev_ops->mac_addr_set() - apply default MAC address >>>>>>> - Call dev->dev_ops->promiscuous_enable() >>>>>>> - Call dev->dev_ops->allmulticast_enable() >>>>>>> >>>>>>> And let PMD itself to decide does it needs to call it at dev_start() or not. >>>>>>> So it will become: >>>>>>> rte_eth_dev_start() >>>>>>> - Call dev->dev_ops->dev_start() >>>>>>> -Call ethdev_replay_user_conf(.) >>>>>>> - Call dev->dev_ops->mac_addr_set() - apply default MAC address >>>>>>> - Call dev->dev_ops->promiscuous_enable() >>>>>>> -Call dev->dev_ops->allmulticast_enable() >>>>>>> >>>>>>> For PMDs that do need to restore user provided config And >>>>>>> rte_eth_dev_start() >>>>>>> - Call dev->dev_ops->dev_start() >>>>>>> >>>>>>> For those who do not. >>>>>>> >>>>>> >>>>>> OK, got it what you mean. >>>>>> Pushing restore functionality to PMDs works, but this may be doing >>>>>> redundant work on each PMD. >>>>>> >>>>>> Instead Dariusz suggests PMD to provide a flag to ehtdev to what to >>>>>> restore and common code in ethdev does the work. >>>>>> My below dedicated data struct comment is to have this flag in a >>>>>> new struct, overall like following: >>>>>> >>>>>> rte_eth_dev_start() >>>>>> - Call dev->dev_ops->dev_start() >>>>>> - Call dev->dev_ops->get_restore_flags(ethdev, RTE_ETH_START, &flags) >>>>>> - if (flags & MAC) dev->dev_ops->mac_addr_set() >>>>>> - if (flags & PROMISC) dev->dev_ops->promiscuous_enable() >>>>>> - ... >>>>> >>>>> Could you please explain what is the benefit of exposing flags >>>>> through dev_ops >>>> callback vs a dedicated flags field in rte_eth_dev_data? >>>>> In both solutions: >>>>> - config restore is transparent to the user, >>>>> - drivers can omit config restore (either by not implementing the >>>>> callback or not providing the flags), >>>>> - an ABI change is introduced (not a huge concern, at least for 24.11). >>>>> >>>>> I understand that my initial proposal with "internal_flags" was too >>>>> vague, but renaming and splitting this field into: >>>>> >>>>> - dev_start_restore_flags >>>>> - dev_reset_restore_flags >>>>> - and so on... >>>>> >>>>> seems sufficient, at least in my opinion. >>>>> >>>> >>>> Hi Dariusz, >>>> >>>> Putting flags to rte_eth_dev_data works, and it is easier since there >>>> is direct access from rte_eth_dev to rte_eth_dev_data, so you don't >>>> need new dev_ops. So this is a valid option. >>>> >>>> But benefit of new dev_ops is to keep "struct rte_eth_dev_data" clean. >>>> >>>> "struct rte_eth_dev_data" is integral data structure for ethdev and >>>> it is used in multiple locations, mostly related to the datapath and >>>> all drivers needs to deal with fields of this struct. >>>> Like [rx]_queues, dev_private, dev_conf all important and used a lot. >>>> >>>> I want to protect "struct rte_eth_dev_data" from noise as much as >>>> possible, though what is noise is not always that clear. >>>> >>>> This restore flag is not critical, and I expect most of the drivers >>>> won't care and populate this restore flag at all. That is why to me >>>> it is better have dedicated struct for it and only drivers care about restore >> feature know it. >>> >>> I see. Thank you very much for the explanation. >>> >>> In this case, it looks like adding this to dev_ops is the way to go. >>> >>> So, summarizing it all: >>> >>> 1. dev_ops should be extended with a callback with the following signature and >> enums/flags: >>> >>> enum rte_eth_dev_operation op { >>> RTE_ETH_START, >>> RTE_ETH_STOP, >>> RTE_ETH_RESET, >>> }; >>> >>> #define RTE_ETH_RESTORE_MAC_ADDR RTE_BIT32(0) #define >>> RTE_ETH_RESTORE_PROMISC RTE_BIT32(1) #define >> RTE_ETH_RESTORE_ALLMULTI >>> RTE_BIT32(2) >>> >>> void (*get_restore_flags)( >>> struct rte_eth_dev *dev, >>> enum rte_eth_dev_operation op, >>> uint32_t *flags); >>> >>> 2. rte_eth_dev_start() will work as follows: >>> >>> - Call dev->dev_ops->dev_start() >>> - Call dev->dev_ops->get_restore_flags(dev, RTE_ETH_START, &flags). If callback >> is not provided, assume flags == 0. >>> - if (flags & RTE_ETH_RESTORE_MAC_ADDR) - restore MAC addresses >>> - and so on... >>> >> >> All above looks good. >> >>> Also, I would like to add the following: >>> >>> 3. Patchset introducing this change should add get_restore_flags() >> implementation to all drivers, which informs that all config should be restored. >>> This would preserve the current behavior. >>> Later, this could be refined driver by driver. >>> >>> What do you think? >>> >> >> What you are saying is correct, but I suspect most of the drivers don't really need >> this restore, but they have it since it was in the ethdev layer. >> >> If we introduce back restore via get_restore_flags(), it may stay as it is in drivers, at >> least for most of them. >> >> What do you think to risk breaking stuff for this case. >> >> So don't implement this in the drivers by default, so who needs it will recognize >> the issue and will implement it. If we merge this patch for -rc1, it gives enough >> time for drivers to detect the issue and fix it. > > It seems rather too risky, especially considering that for example, there are a few Intel drivers which do not have maintainers (like i40e). > So, I don't know what will happen to such drivers. They may be left broken (if they are affected) for 24.11 and future releases. > But I agree that if default behavior is preserved, this dependence of drivers on config restore might stay as is. > I'm on the fence about it. > Yeah, not sure. Do you think the dev_ops function can be implemented in the 'ethdev_driver.c' and all drivers use exact same function? So this reduces changes and duplication in drivers while preserving the behavior. >> >> Only we may implement this to the drivers that exist when this restore code was >> introduced. >> I mean whatever driver exist in the initial DPDK commit, implement this logic only >> to those drivers. > > Seems reasonable to me. In this case, it would be igb (IIUC, now it's named e1000) and ixgbe. > >> >>> Also, there's an open question about 'stop' and 'reset' operations. >>> At the moment, ethdev layer does not do any config manipulation during these >> operations. >>> Maybe we should limit get_restore_flags() to 'start' only? >>> >> >> Ack, I was about to suggest the same, for now only have 'RTE_ETH_START' >> as a placeholder for later possible usages. > > Ack > >> >>>> >>>> >>>> >>>>>> >>>>>> So PMDs only will provide what to restore with an internal API and >>>>>> common ethdev layer will restore it. >>>>>> If no restore required PMD may not implement .get_restore_flags() at all. >>>>>> >>>>>> Additionally, RTE_ETH_START, RTE_ETH_RESET etc flag can be provided >>>>>> to internal API to get what to restore in different states... >>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> Yes, same thoughts. >>>>>>> >>>>>>>> Instead what do you think to have a separate, dedicated data struct for it? >>>>>>> >>>>>>> Hmm... not sure I understood you here... >>>>>>> >>>>>>>> >>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >