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 C93E045A58; Wed, 9 Oct 2024 03:07:46 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A5A2940614; Wed, 9 Oct 2024 03:07:46 +0200 (CEST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2050.outbound.protection.outlook.com [40.107.243.50]) by mails.dpdk.org (Postfix) with ESMTP id C5668402B3 for ; Wed, 9 Oct 2024 03:07:44 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l5y2dWlNnCJjsavA7l9D5G6zdZfQUBB2/ehOsODs6p+WMvV5tLq/Nd4YCBNqZCgiMq5gW3qKpgdOzeASrh0JBR0T1EZJXY0rLvkSzJsMxhskzfeoe3tUCtT48I7vzzTnr54L2m6aMRkYrnuzZA14gyd+ODResiuVy+2hyZIr09BsL5ZqA3eAoKWrjlpBETin7Uod6VPVgQvUYC5AwC4phDq73lezfcrAqGtrBtHOdQca5FMvivU/yD8Jhz1tqdw2acKgC4wJoMoQbjK4H96cx04wyrE7TPh8MvvXwSmaeXj3rsyTxPTc0fLRDbNgXkkPKo2YBn226KkGwvtML3uN1g== 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=9w7QBSIxwlTapMEZpaKfSv69GPFuulHHFgUKx6/PRPo=; b=fqg08x9HJW105WzO+fVepgZ5VrbkH1AZ2aj549jWb0GG8y6PgiWfaG54Nq5QaGuueoEHW6d07BdsnHOkM2O3jPPJdXKJjgqjACLikyr8AIYOSmEQUI7oCdOpuMZUzZ8vcgw+J9MRizgVKwr+a1aaHLUk9cpjNpljfVYF0lLTzCFjdu0IemaCRVd/j9nI7++LhxqAJtiUoVHsYDE+mDMDYI9V3j/kjwSH/7X8AifstmJL6NIgcj9SS6+WLO1G6FWnbuTRMaCdrRKluQ/+Fu7c5ir7X+v8GHpafjdPxk9Z21QeY9FggiEIzriHVILlPa3Shf15kicevyqbmE8NoY3VYQ== 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=9w7QBSIxwlTapMEZpaKfSv69GPFuulHHFgUKx6/PRPo=; b=FOulurTZjTvrpLIahnx9UbgmdtsPaSPyTC117vvAtwFqwqelqhfyaMrsYN14E4O177PaSbYKpNX74Ao97Wh1Wk85wNwmp/6I7rqeT33wKUKlKaWjTY71XBJutMn0PibjKevYEaDafmz3qPOJri5qlEWXYeU1qHw81IOacoZD/rM= 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 CH2PR12MB4055.namprd12.prod.outlook.com (2603:10b6:610:78::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8048.16; Wed, 9 Oct 2024 01:07:42 +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; Wed, 9 Oct 2024 01:07:42 +0000 Message-ID: <8a6f760c-8bc7-46cd-92e0-a8af66114e2d@amd.com> Date: Wed, 9 Oct 2024 02:07:37 +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> <3833d9270fba43af9d17765056911940@huawei.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: <3833d9270fba43af9d17765056911940@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0174.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::18) To SJ2PR12MB8830.namprd12.prod.outlook.com (2603:10b6:a03:4d0::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR12MB8830:EE_|CH2PR12MB4055:EE_ X-MS-Office365-Filtering-Correlation-Id: f4bbf133-9210-4969-94f9-08dce7fec6f7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?VmJuejZITXRTK1FHRDdJQlFNOXh5eXBzOStLdUUrSUdsM3h3R25NS2Y2QkVq?= =?utf-8?B?eUFiZDhveUpZcU5sTytxWGFTTEdVZjVUdmdkZjZsZGI3V2VBUUtlMGViUEow?= =?utf-8?B?bWY0bGRWS0ZaU0lSdGV5VWU4TWZjdlZ2aDAzOWttVDBkaHluR3lLNW5NcFgw?= =?utf-8?B?dFA2RElpOTFFL2ppeWx5RFZIUHoxYm0xZHBDOGJTUmVXR1RyeVNQRFpKczh6?= =?utf-8?B?UG1ZQW1sZzBmcHVUT2UwZEtSRDN5b0Vucnh2bUtDMnBaVHBxV1pyVkRETVoy?= =?utf-8?B?OWdISExBR29MZW4wUVQ3aE5QcGJzZDJVRTN6NWZHdDUwT2dLZmxFUXpIRWlv?= =?utf-8?B?cWdyZ291KzhFeFNjczB4cE1MN3NiSzF0eXFvbDNnN1VCc2tCMnpoWnNNaXR0?= =?utf-8?B?UWhsUUp5eTVVdkk5cEJQTDBUWlYwM2pqeWpHY05qaThxaTQ0ZjFIV3RHLzlZ?= =?utf-8?B?VzBMQVhjbWRCN1lBdG90aDN2aUhKR1VjTEh0RTVEVlhGZm1PeHFQbkRXcDVJ?= =?utf-8?B?eDA3QlVXTHFiUDhmVVJYZDJEelZGaDBSTEdhSHFQN284WU5LNTBiVEhWc3hI?= =?utf-8?B?dE5Gb3U3VVkrZzdmVWJDajFlUndmc3RqNTFSNU5wUjBiK3UwdnZFaVZaVFE3?= =?utf-8?B?Yng2Qmx6Z05KNS9hUUFsZ1NLaUFWZFIrVWdFS2JLdWxDRFE3QmliNmZJTTds?= =?utf-8?B?cVVTU2IwMDRxY2VMenFZTnBJTHU4NGpTcEROcXlnU3dQcjVUcDg4MkhDOVNl?= =?utf-8?B?OXFseWtuWkh5MFNyRmI3YlF2dUJOZi9lcG9OZFZsdnViZEl1YUdBRHcyZHNU?= =?utf-8?B?MFFTVkZLY2tUeVh4Tm8zTnIrdXphQzg5Lzh0dnQwOUdYZm8ycktkWERUOFZl?= =?utf-8?B?Sjk4TlZsb3l4cEl3eHZNaHNjSzBhREJRZHdkUmlXaFpDeHZkQkh1UXZVMkZ3?= =?utf-8?B?bUttak00VHZXMitUR254ckJQZ1VBaGFGL0pTcG5DUGc2OEM3SDRBVHNlNWsv?= =?utf-8?B?WGs2M1pGbnNNTHpDVlhjRjkrY0ZRTVRiUFZESnptM2x1eFJwcDdzTGNONUlH?= =?utf-8?B?TTFlWjIwQ3QwSVBObFY2blJ0c3VBZHAzTHVaVlYrcFo3UnloYmVqVzhXZTdU?= =?utf-8?B?SE1YR2tNc3JtNDczT3piQUh2L2Jxd01oVkNrNnVhZ0FCay9oNjdUMkxPTWI0?= =?utf-8?B?b3ljNUdLTXVwKzFVZTBCZHlzTDc3QmYwR1NLdzNicUhUTXJlNTN1UVJzbjVM?= =?utf-8?B?MjRmYklhY3I0WXBROW9UN1crSVF0REkwSk0rZ0RtaVVtMUZzRzUwaitGZ1dC?= =?utf-8?B?UkR0bjNTdGdLYTVkVzFsR051TUVnTzB0bldCL3gvanB6SUd4Tnlld3RCQzhJ?= =?utf-8?B?dk1PWFZwMkFlRFFsdkNjQ1ZFZFUwbkt5L3c2ZzgrQllRWEl2dDlQM2xFb3By?= =?utf-8?B?WDlCbHJ2dlh2Sndub3NrY1gyeUVrYk1pMmVkNlptTHlaQlV3RmZCYnhXaFQ1?= =?utf-8?B?akhWcm1mOTZHMmhhWkJJckhwQW83b0RILy9zTWRwUkJzZXBjMGFHSUk5aDJu?= =?utf-8?B?eVNHNjNaclFqdEYxS1M1RGVEVHJTcDRyb3psRjNqWXdZYyt6NU9CRm80SHhD?= =?utf-8?B?bThwUUZDcE43eTgvL29DRkZHQmR4Ym1TcGNkbEYrWkU0dTRjS3hSKytQY0J4?= =?utf-8?B?UXJabGc0YWI5cVoyeFJZaWpaMjdVRDQwaU82RWVJdWRIbmEzU0l2bjJRPT0=?= 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)(366016)(376014)(1800799024); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L0MxWHdCWHplVEJiM1pUVlFFZWk4bzJkdHpqMmU5eVNBZ0NqSWVzeGNsWmNK?= =?utf-8?B?Z1lIUjNmY21GdjdwRkRIMmFXVXVJOFBmcUNWODIzM2NSekxqK21LdVlINGlN?= =?utf-8?B?aFdXZmczT3ZSL3JsN0NFVHZ0N29TWm1rbTBiUzZGSHpKU0lNVDFiV2FUdXZO?= =?utf-8?B?UXUxYXlZK1ZjakkvcFVxWS9aNXlKWHk5KzNRVEJVS0RUN3lyb0RFMkNKUXR2?= =?utf-8?B?dzJuNWVLZWdXYktza0dBYllLam9MOEFyeFUzbFZBOTJ5a0YvR0NtYTFidGNn?= =?utf-8?B?eC9VbHdhVFhYMkg2czhUZktLRy9tbGhzbzFOL3k5blIxVzIxSzUxZmRFV0dt?= =?utf-8?B?bHE0NmxUUkcrYjRjRUsxai91OTB2bXl0WlN3TllMdmxrcVFSbmZpMkNWRnBi?= =?utf-8?B?YUVPenYrWnMxdWJiK09PR09qWDg4aU1xbmR5dGZYSUpseW9sY0NMdkRWQ2xC?= =?utf-8?B?L1o4U2hnYy9PaEthbjdmQUZVQWIyM29QRTIrNmRyb0RTQ01MV2ZFdXRDK3Nt?= =?utf-8?B?VHlFejBHbXY2MWJmRVIyaXA0Z1NJQU9rYzNnSjR5Y3NpeXEvNGJqV1A5dkRM?= =?utf-8?B?Z0MvRVlZZ2t1UTVpTm5iQXdtQU1GWmVTQWZBRHhxN1VTOEF1bEd3YUhkdk1a?= =?utf-8?B?Tm1kQk40Q3Evck5tZEFtY3ZKMjdic1lYNC9XSFFTYWhpVlhSbjd6TG5zVXZQ?= =?utf-8?B?OHVKc0t6S3QxSTArVktzbHNTRTVvMzFEdXl1WEo4dE1pV3NFTkxjVEttQ2NI?= =?utf-8?B?OGhsb09DOTZjUGJtVFRjOGpHd0JqdXhZdGRRdEFXaXJHSjRGbGNTNWVYZ09o?= =?utf-8?B?RW4rRmR0SVJwNDV3QjRGeEVoSDltUGtPRDJKMk1NQUowbFRvaElnVGRGVkVu?= =?utf-8?B?WWNmVHl1ME5TczNJLzk1MWtUUWlRZEpRdU0yMGZoTFllK3BJRVBqUmMyVDc2?= =?utf-8?B?UUtNWFdZTFdDVzA4eGVoVWM2a21XK1hidURyeWFQVUJnOHd2MnhXZkxOdEFD?= =?utf-8?B?aCs0YmxBSjhNQzhOeEdaS0VhRDU1eVVaUDFkcXZPWjFYWUJPZ0w3bjErbEUy?= =?utf-8?B?UE54aHNPL2pDdEVQenI1VWxYaEtIblFwSDB3U2pFVVRpRytLM2ZNS09kM1N0?= =?utf-8?B?QXNqeTNGWEM0eWYwbElwbXZQRXk2RTV2RFdnZWRSOVhidlZ5Y2tNMU9lTmxK?= =?utf-8?B?Q1pVUVFwM1VpMVZicEVQV2UrYWdwMWV2OGZseVFDaGdBTzB3UzkxQ3E4TzBn?= =?utf-8?B?T1liQUdYZHZTMy9wcWVXUXBCRUdiSXRsVFFFNEZod3pZRGZrb3JJRVdkSTYr?= =?utf-8?B?WEd5bjE4SHpYbWJleWJFck1kU001THV5ZGhiZ2ZZa0hNYmF3QzFjSWtubm81?= =?utf-8?B?aVBQUzNFenljSXY2NVZNcHRVaEJFMXczUDhnWjFVcWJlV1hMSVBXQ1NjVkd1?= =?utf-8?B?Qys3aXNteThUWGlVa0w0SCtsVzlqMEgzeTdrcHlnQzZXTTRaYVYwYThUVlU1?= =?utf-8?B?RTVzcWpBeEZlS3hXbFJKNHdrbzNFcW02N0tSUlpiamxidmxFTFZEVUNDbkJP?= =?utf-8?B?dHBOMjJBTm9Ea2RzbjE3NWpTZUlpOXZ6dXNTdWdERjczT3pWNE01aTBTNzlE?= =?utf-8?B?Smw3b0JSWGoxZ2xFSlovU29sS1Z6eG1nZmN1UHpVbS95eXJPS0o0eFpFSWNv?= =?utf-8?B?VmxaUnlCeWZOSmJnd09FbDV0U0Z2SGxHSlZ6amhjekZGVU9aalV2TTZlMmpP?= =?utf-8?B?UVRJeW5kYzlzYjdqOWg2c1QxblZnNGJDb1Z3Y1o4bVJYQWUzSzh3L0NoVVpY?= =?utf-8?B?RlM5RVFudHY0dE5UK09xeERxWnVCTEJhWEVFYnQ1MGs0SEs5bDdDbHVKelJQ?= =?utf-8?B?eFd2c2hJVFdFS0s3VVFyQ3VobDRUSzFmbGF4aDcvUHdLYVhraWVha2JBQkNM?= =?utf-8?B?bW9OdnZKMllBb0pZL2xwd0RaeXRxUk5vVXVqUGE5d3l6dHpsdlNveXU1cDdC?= =?utf-8?B?cFE2N3JsL2RnbGorVzhmNGFqRkEySWhERllSZEh6YjNRWUU0dURMRndjTFQz?= =?utf-8?B?RTEzbGZTckRETDRmY0dmOHMvTVlUMFNJUUZhN2Y1L2JGeFdZWmcxdmpwc2lO?= =?utf-8?Q?rEftMsfazL84gj1UOulsjbYvH?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4bbf133-9210-4969-94f9-08dce7fec6f7 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR12MB8830.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2024 01:07:42.6249 (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: P1Zdji6az2az9FaDIxmW2TGUhG4dVPX4tWRASsL4RuwVTK1B8wCSRD5/fkBY0R7o X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4055 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/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() - ... 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 >>>>>> >>> >