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 0455B45B0B; Fri, 11 Oct 2024 02:02:43 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C3576402E1; Fri, 11 Oct 2024 02:02:42 +0200 (CEST) Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2064.outbound.protection.outlook.com [40.107.101.64]) by mails.dpdk.org (Postfix) with ESMTP id F33C6402D3 for ; Fri, 11 Oct 2024 02:02:40 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EuhrC6ijcpNgbkv3vJ3XaaWESuUivwHgcFXIpw8BfYTHFkgcOISM5vCrBevIyrZ2tSWsq64GVd49rCP5tgtfL6EJCHDPabD/6D0ohvht9aVvjBL1npDtuPg7J12LN91KYIsceXwJhheX7VxGeNyWNG5P/2jiabUUk+onJHpRK0bNdBRexbcK0IO2dixXW7xZPnbgV9pfRjrSLpPxc9L8g2rhWKEwi66yDXaiLbO4bOTr83CoJxR2tJd185LDwxAugt90DaQ271yCt7RgclPdU3aT6NcpRjLp2EsekJT7SN9gErjguP92fklbJWq/XB/i0gteemlIKCgvL8fMRqMqHw== 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=HFEAfel4fSgHEpffGiNugCIM0JUvpZLVpRm3BbnhW04=; b=FLT6ScNUpLE3HS5imbuAtnPlkCtiV+XjZPKXCeB0ab6h43Mzd4DQFDUNlXXkIFDgSGfvIrjjBW5w3zb4NrMpLrIgA8aaFzS1H4ivUuRE/paNYeXueGCbKGE8u8HDPuLyuC0jZp2JZXwryVMc5onSkAfPwDUp18MzrFO9JRTYuxmszlMCu1RNOx87nra1tTtAtXOhnu3Yy0brbu5OOOnvi1YJYs6RdoDJ6qMrppLKM57WqFWm7qClS3P2dPeMTH49PoGy3emVjCrvddCwKNsH+vHiK3yWmIZv8vKmBV6cqHa7EcVzqasQTYvuY4sbIkXEVJ0QGKOgoUFscBW34/9e8A== 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=HFEAfel4fSgHEpffGiNugCIM0JUvpZLVpRm3BbnhW04=; b=BlPYFXlLC4JaITtTAvUVzKSifB2ci7x9QK+IuEv5feT8DBPgjjVVU67spGpE6aARgcWR9uxs9bmHQVBbtx86mtXLE/OSTDSmur20zE23V056Dd4wu1OYY9OSG3u6mYI10kfjlpRcYT2E/kHQrm+1XoVTf8tFKAaLB3BfvNAj/1w= 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 SJ0PR12MB6856.namprd12.prod.outlook.com (2603:10b6:a03:47f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8048.18; Fri, 11 Oct 2024 00:02:37 +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; Fri, 11 Oct 2024 00:02:37 +0000 Message-ID: <24aa0035-79af-4f15-8dd8-fb8cd625e4e6@amd.com> Date: Fri, 11 Oct 2024 01:02:31 +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> <8a6f760c-8bc7-46cd-92e0-a8af66114e2d@amd.com> <5ef19db7-f6fe-4a48-8497-e17b33a262b5@amd.com> <6e2487af-5bf5-4a07-bc9d-2e6f1a1def19@amd.com> <0d526176545845c49d67a30855202f2f@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: <0d526176545845c49d67a30855202f2f@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0036.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ae::12) To SJ2PR12MB8830.namprd12.prod.outlook.com (2603:10b6:a03:4d0::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR12MB8830:EE_|SJ0PR12MB6856:EE_ X-MS-Office365-Filtering-Correlation-Id: 145828c9-1b01-496e-a7a4-08dce98803cb 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?OFp6aDRLZHdUb0NqQXhOMGR5RHhGVERyMW14OUdwbFpWUXFnS0VGRjV3QlhM?= =?utf-8?B?K1RtbWMxWE1lWTRoZjRKVlVoZmM2ZWo0OXZPbE5peGtlWUV1UGthSEVMRWJM?= =?utf-8?B?cHhFZXlWeXB4QmdzR0xJeWRKSWNyUEYzc09iS21RQ0JONW9VakJ2YXpRWWNZ?= =?utf-8?B?TXg2dFJCaXZOYzlYZFgvUEdkYk14S2FTcGhETHdUZnpGNlE2ZVMzTEhVWG11?= =?utf-8?B?SHNITDg5bU42NXpvdnA3ZkdrK0FXVURrcUtHbTVXb3VadTdvNjlYT0haYjBB?= =?utf-8?B?bVJPaDljR3gyemNFMzFQTzRud21YUmcrMHI3SlU0YjN0OFdYOEJtVmhiWUZM?= =?utf-8?B?S09kQm44eHlRcUhFa3JmS1ROU3RkTlFYblFxdFNTRlpoYi8yZnp1SnoxNVkv?= =?utf-8?B?Z2NINVpFcWVBSnJmZ3hYa1VqdlB4WENjZmtrUVgrQXltUFk5STM4N0FRNVlV?= =?utf-8?B?ZGJKS2NsSWlZenNMK0lVd1p6QnZvYit0bDF3MERndDZRWUZwUXVmWnhBM0Zr?= =?utf-8?B?ckthWHJDWURhM2k3RmZydmRISWhKSHgvZEhFaTEwb3A1QzZ4WWFCYnI2SC9G?= =?utf-8?B?NDhQSGwwMUQ4MnM1NnF4ZG90d0sxYXVDRGp5S2RaL2FwRnh5V2w1akF4UURW?= =?utf-8?B?cmRHNG5IbmlrbXZ1dVpNdTBmZ0lyaFd1d0ZYOTZ2eGdRclRiMGdDRmhzaWh2?= =?utf-8?B?d29Jck0rVzc2Ym5HQUdLYXM2WTJ1cnFEcXVMYmhDbkRrYnFYVm9oY2RocHRs?= =?utf-8?B?TVhmRlZRV0hJUGxPcGF2M2o3cEtITk5VRy96U25rTG1BaG5vbkhUWXB1Nmd0?= =?utf-8?B?Wm5BbHpiTkRsbUtIc2xaOEZKYWcrYmdRbk92R0pZaTJRNW5yRkwyL1Jya0g0?= =?utf-8?B?OURsd2RoUTBmMDRKYkdlcnp3bkRjQUNOMzlSRVNZSjNxTStYcWhESUlkWmha?= =?utf-8?B?c00wbDRCblhBMEZZOUNaNDVsUzdWYURHWUZ3Qk9qWTVRdi9XckttTHJmaTJF?= =?utf-8?B?K3hEbzRvaTBTZ2ZpVTY2ZGxFT2hvZitxMy94VTU1MUVnYjB2UkNBcG5IeXpM?= =?utf-8?B?cGVhZ3I3MEVnYWJrVXBqYUFkUDhsSVVZYWszWmJxV1ZLLzNqazNKQkhOT3pY?= =?utf-8?B?dVp5ZjlCd2JiRVB5UWY4bjF0ZU45dkhmRDJOOE1pdUx4bkR5MDlaSmE2Rmt1?= =?utf-8?B?V0VhM0UzMk9oS0Y4SHRvRlNKV1d1TDVaVTY1M0R3Wm5WQVFJbVdJRDh2My95?= =?utf-8?B?OTdBZzB6V2cwd0ZTdXFMczFZU3BOVXc0Nkl1NmxIZjFwbWFFVVpJMnZTalQ3?= =?utf-8?B?VU1Tbm4yMlhJUzYybGhqZEc0UzhBOXVudm5XcGZPSjJlSUZmQ3Q2WTBpRlAz?= =?utf-8?B?RDByM0E1ejZHOFF5UW5sSG44N1VhMk5CeE0rQ3pHb2hmTmxDUEROeC9UVTI5?= =?utf-8?B?bG92b3lmRlIxMUl4YnlMbERveE5jbXRIY1FzbHVtZ0tacVF5NHMwdy9CUUpG?= =?utf-8?B?Tkg0ZDd0Qk1ESG1wbGJVQ3c5S0hud3QwbE1vWmxSRTd4Ky8xQzFhMTJrOUtx?= =?utf-8?B?UVhKS3d5aVkwSUhCc3RMaC9ZMGNaRmJOSGphRlpEbWl5c1c1MjZ1em1kTW9r?= =?utf-8?B?TDA0cW5VTi9GMHlpTVhBWXQ5VUxHbHk1eTdHUFdwOFo3NTBVUTRjazVvUVRx?= =?utf-8?B?WHgwOXI2cG1naDVWcWNEeDI2RERpWEMxd0FTQ2xRSWZBZmlBb2lWN0pRPT0=?= 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?K01pZUpxNlN1cHFuVTluVkZpektNcnNSbTROZlZtVVdsdC9yNGtxajZLeVBx?= =?utf-8?B?ZmJ0S3dHVFpZckx4bndPdkRWdk5Rc0pZSEpXZzJ2d1plR1FYYnZGeUF1bFV3?= =?utf-8?B?V1lBdDNRUjNjRUc4NS8zWmViaFpFUmQ4SFpnZUUrbXBoaVJrYU5FUUZFczN2?= =?utf-8?B?T0Z6MjdIemZjMEFiaFRzNS9KallkZHRXYUJFUi9SSTgvdG1VMjNZQURZY1Z0?= =?utf-8?B?WGFURXE5UTcrK3JYbTQyK1BwWWQ2MGVMcjhJeVFJQ2tUMWxaWEZzQ0w0MzZn?= =?utf-8?B?Sml6MlI2OEdXMGhXU2Q0N0Y2b25wRkxRQVlLV0c1dmRXQXdwOVNUTzdKL2U0?= =?utf-8?B?TVN5VTFqempxTCtKWjdiRUVTblBmbU1qMnBubm9oZmRpVnliWk9YYUVXUEtP?= =?utf-8?B?R3ZJUkVCVHB2cS9iTDJ3SU16Y2JZc3VFT20zVUs0UC82QWVHKzM3L3g5THM2?= =?utf-8?B?U1F2cFZ4MU9FSlQzRGlTU1l2ZzkvT2dqeGhHaHV4d0RTWE4vdW9lZmZ0eUhr?= =?utf-8?B?TnVRMk1TYlVVL3pyb2IzUGpudHF5dFdNaXJsTU1vYUdNK1p4TDlBVmpaMXh4?= =?utf-8?B?QmxSS1c4c0RKU2NCVHRpRjNXUkVJRWpNdkFzZXhkWHJTb3NPMGpQV2Fxbm1z?= =?utf-8?B?Zko0RnYrYlNrR24vNkdDZW1JTzRQUUdKQVhkUS8yM2IzUnhOanV6Y0hGVXFi?= =?utf-8?B?Q2Qrc1JPL1RHYXk2WXJXbTNkNmpneGpnYlFkMFhaN2d6d1FrY3FlcnV5MmFX?= =?utf-8?B?Y2tGd0gzb3Z0S3BMdEJTdmtDUlNzZzYzYVpzSnVJVDlJKzlFRVozZWo3VGdh?= =?utf-8?B?K1l5T3R6TStrTlN0eXF6NDkrZURXL0lvK1NsMEVSZ2dFRG5wWkIzNUgrWnNR?= =?utf-8?B?b1VRa05HWnVtRlVSQ1RCa3Q3d080UVZ5S1pEZkFiUnRIQitsMWZFSkQrN2hD?= =?utf-8?B?WjRlN1NyR1paajFqTHcvYW5lTlhTK0FjMzRodUdTSmJEa2VwMFdhVEpkNUJ6?= =?utf-8?B?VlVLZ2FWdVlzQm9ISU11dzJ5SGdVSGJSZjRPWlRweVpuY3ZsTmlXY3J4SEhT?= =?utf-8?B?dEdIN0NxOWNydHJvOVN3MVpnS3RqTStJREY0RXNHMlg3VUJxU1ZjdjJ3NlpT?= =?utf-8?B?UUR0YVI5OTBaWDVIWTRQV1UrNzgyMDZGSDFYV1NyWUU0YnM4cTZSbDdQdndz?= =?utf-8?B?aTdLbFF1Y0N6SlhxWVF6VTR5NjlNVFFMS1hXNE96QThZdzlTSU5ZbllRaDRp?= =?utf-8?B?Z3M4Rmw3bG5WcU5KWFQwM3IxcEJPa2k2RTVGN3lvZmkwY3p4blUwWVBSOEh6?= =?utf-8?B?YVIzTFp1ZDlWbFhXM3BScWc4SFRmbFlZeHNIYW5MaGNPTS8wWXlLbWh4MXYy?= =?utf-8?B?MmMzWkFxaStKV2RrWTVaL1c3cTNiSFpuVm9zYyt1K3NJT0dpVUJrTEZsd0ho?= =?utf-8?B?ZlZxMTc1TG5VTnJVMVdCaUJFMEtYV1gyOU13aUxJODgxSGlrY1p3WGhDeDRx?= =?utf-8?B?d2JvMVBwQWZoUXBtSTBCRGZ0RXNyUlhoOW05NFp3S295ZmU1QzZabjdXN1pL?= =?utf-8?B?TmtKOHVycnRPSlo3T2lKdkt6NG84b0IvbjI0eWRHM1NpM1lsZDNZSlBUSUxq?= =?utf-8?B?ekNlVVllYk0zWm9ZYS9Ed0lQYVdFT25tdVY1U1NwbEpuNU12ZWhUTE5jZ3Ur?= =?utf-8?B?d1hyT0czOC9yaU1yOWFpdjk5cTlTRGpEYVE5Q1BFQ0xLOVlBb0JGdzVMY053?= =?utf-8?B?VnRsck1RTldJZHVDcVVOUFptMHFxb0ZUMUZPRHBaRzBFMHUwdlNDTVkwdkd4?= =?utf-8?B?bkRYcERRSnJVWWsyMTZuU2kySnFEQ2lHU25FNzF3Z1I4K2U4aEJ1ditIOEw0?= =?utf-8?B?emJuWSsvMWtGbkZrMDFHUkI1T1pxdmNzTWRqNWR5Z2VQSE03S3RFbm9WTTJC?= =?utf-8?B?ZHQ3V0tHd3U5aXpZaUcweUh3NWJwWUJQNzU1R0RwT0tCcC9NdjlGUHgrR1Q4?= =?utf-8?B?aEllRmVQeDBwT3lWN3RjRXFvM2hKdVpib1NtMUtqQVdBaHAzNkFDOCtXKzhE?= =?utf-8?B?dnVrY2NEUkhCN05WMlc4Ull0aThXUFRhRFVJcW03YnN0cENaSktQbmdSSVBq?= =?utf-8?Q?PrCW1H01rvNvxW71NnTsnSt6s?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 145828c9-1b01-496e-a7a4-08dce98803cb X-MS-Exchange-CrossTenant-AuthSource: SJ2PR12MB8830.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2024 00:02:37.0481 (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: oIJCwvh77zFzspfcMc/pJ7f+ID091URGAtwk1yjwkPYu2bs77YxAsOtqXCP0mvi1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6856 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 11:58 PM, Konstantin Ananyev wrote: > > > 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. > > Wonder why it can't be done visa-versa? > If this new function is not implemented by PMD, then simply assume > that everything needs to be restored (as it happens now)? > True, this preserve the behavior and prevents updating all drivers. I think can be done in two ways: 1. dev_ops() tells what NOT to restore, if dev_ops() not implemented or it returns zero, restore everything. Here what not nice is what to restore in this case is not very well defined. 2. dev_ops() tells what to restore, but when not implemented default flag value is all restore. Which is current behavior. I am for option 2. and I assume that is what Konstantin also suggest, but I want to clarify to be sure. >>>> >>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >