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 7A31E42653; Wed, 27 Sep 2023 18:14:03 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4F14240271; Wed, 27 Sep 2023 18:14:03 +0200 (CEST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2080.outbound.protection.outlook.com [40.107.93.80]) by mails.dpdk.org (Postfix) with ESMTP id 2EABF4026B for ; Wed, 27 Sep 2023 18:14:02 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kDTwyxW3B7jdt1H4AeocOHxghroeM92pnBRiSOlaFJf+rOT1zm4Ug+34PBeU7To+ffdKTXVfeeTSBOsOSGcynS6gf2vXkuIsl4deICHE59JL9hamhyeTOc5zQWNgp4fJGtXEV9yHBCsrpzBEMOrJvFw5wc13z3p23Mus2ljIrIL+9wcwWZY15weoEidcO/4Ify0tr3kAvs4xGjdSSzXEp3UpLvnFY7LXI23Ni5w51A2oQXSfDtojj/9RqWfT8qZT8uS9KffKAaJLzYCYJ/DjdjU7NiV9y+uasj2AZ2B4VaHxT+gnIPST/bunhvuKrM6CUT52oo6/Y8RSi1GDBXPMiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=zZiyoHW/fTKZZadBKLUq42nQtdNa2E3Azzm8knu34zM=; b=KCQhIqAupWKWdUwQTiutxpS+7zfBePr9pPfJahCKnOBxlc3HDblXvKV+7P363pKsy1eBKgusj2uHkKoFrEAKBebl7v79VbPjYDMWpZgYGMrVouWoI0S6NrZ4hIFyRuyl/MBlOcTuZ6gG70eddX2Fmphsh7ZDngCnKkSoAwC4xuCFHsappjLxD0sIYwbaNOq1lLKql7z1S2+NagQD7ECYTVKEhrHwy+K9vKWIVYIeh13ITzBrdRUcus9hxvKM1EcwEVapfD0ubWUA5oGU5OahNFaXVJCOAWPhHUb1piQGu9KSfAVWmyAuXeByifp8N7ADB/McaRhIH3HU8QDhxeofzg== 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=zZiyoHW/fTKZZadBKLUq42nQtdNa2E3Azzm8knu34zM=; b=RUUFYCkWlGf04EfNZ8xYSnEcwFNYZ15AtA1J5moMYr8OKn8QplYhsu+kriB8plB05wKbn0Tq+f4p4CP60Lde8C8EggSR4wusgxrKEn80/UvDigWFFvhm1hroOvLHvNNychgviqz5FJShfmu/LYDg3gw7s0TYphCjr8Hl5EaVMHc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by PH7PR12MB6908.namprd12.prod.outlook.com (2603:10b6:510:1ba::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.20; Wed, 27 Sep 2023 16:13:58 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::102f:c69b:d3e5:7fe8]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::102f:c69b:d3e5:7fe8%4]) with mapi id 15.20.6838.016; Wed, 27 Sep 2023 16:13:58 +0000 Message-ID: <408f268d-6ab9-41ca-8adb-bd8d625627c4@amd.com> Date: Wed, 27 Sep 2023 17:13:51 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration Content-Language: en-US To: =?UTF-8?Q?Stanis=C5=82aw_Kardach?= Cc: "Tummala, Sivaprasad" , David Marchand , Ruifeng Wang , Min Zhou , David Christensen , Bruce Richardson , Konstantin Ananyev , dev , Thomas Monjalon References: <20230802211150.939121-1-sivaprasad.tummala@amd.com> <20230811060755.481572-1-sivaprasad.tummala@amd.com> <20230811060755.481572-2-sivaprasad.tummala@amd.com> <530da851-fcf3-4dcf-8f51-e11e9784763b@amd.com> <6434ac72-0f5b-450b-900d-e34078756355@amd.com> 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/6BQJjb9DJBQkC+3/YAAoJEFRTPtCK Km/6d94P/irGq3mPa7LamXMIioQ8i6ppMSjpr8g+SxH9RnzbmoUjUY6hVzCpXYxEejiJHubg 7lwD+bOocYpiU8Pe0UncVBhIPNk/dIWQAyH0IWK1nd+hOnjxHv3AQpP80Be2o1mUn3oq/b+B QYiyvvre2gIugYq0hzLcG7z4zREeT+Nl0DMDfnLx+Tj2FAOHrOfudUqjdr/VjF5PoTK0bxnb Brqulp0I0ft7hNsufhzf+TlqaB5l0eQO4gDo5xGTP97TT1cGYsXVMsyDhHqW6P3cuj8kkLkO Ch4oq8OLL8GElgRy5y5svU6CJu3f8hT9aiqIoaRpfNv6N8iEk6g4/HNN+uydb9YCA+1pbwBx skmDhtxQrmXpI+Fmfq0aX2NmqHcy6JR8Ekm/nfwLAW/aDpwoMImVN5pPXtOBSjYi4pj7hiJk UA0ZFi8HCW+fic85p8MXn1GPDmbO82Mm3JVJ1uJNAzGsBbW5SP1ol6+XTeaSxcmzFlrDs8vL XQJMRTpcG6Pti7GbbsOtldvmxRQpq9PmCgQg9IrPXpMoaKE3WwtiSiCALs0kYj4F+hhgAfjI RsOuaAJTnKYW31pC/QdroMNAEqIpLveql03jj+xD9ntJIVAsXiCitsLIXzKP0L5tcHkoVLC3 NAjVYq6XkAEssPF4mMRLoEwpvxOytHe1BCJoRl0YA0aQzsFNBGJDD3EBEAC8fBFQHej8qgIG 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/oFAmNv0PAFCQL7f/8ACgkQVFM+0Ioqb/oU9hAAisAJJ09j/kiEeA1HGKUg3DyFnYW22zRL z1IHYmcHQanMx4+FAwsb1bonVldQMIYNJ9z69UNIU16zIqLZt3D5QK7Je5F5q4NZgfP2jtjX rc3jyu0PuDerFZQyxNcYhhmlF9JO9NV976WYbBAM3AAr0TDohUk+YicYTKab+ZHYOABXbqHX qi+bzDCH1vKBDfpJviprthhK1tIABUK5lsp9aFwFU2jfu2J3XX3pwQhPMjtn2C4v37XUnOqM SJPr2HLU27IW5I3BBpJn7dZE/BkmDmnceHF8E4tRlXCQ/cf81+eErL832sfhVJo1MpubKh3B j89ZLmw0cDXZP2hqlC9vdXnoWWHI8PDPkiw9z11yLrT9Wd4cTJTjFV49Z9G96rgnOtWDcZ1J xHBAnXYQ7V2k9abY+ZqY1PtAPr/smqzQfPHXyTAhRVZp2f3yQmj7UqB07FJuLQjJ4CGk97Qx ///qeSg7D8x/sGEA8Yp2jgIj6u7tspuz+RgBYrWpfI0VIHhWED0jNXzqztrVX18CzA6r0ReY SG+CSyycKkco6UI9ZeUrXFwnoUJqIJY9wTJo5gD9EgGIbItv3qWTq29dihLYpzd6dqB708k7 4RBz9051oLaFVGkguFw/tXmA17nx+c2uR5jx8wb4j68umG2X++0dSta5eHAVhmtXvrqPW6Ku 3FQ= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0194.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:318::9) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|PH7PR12MB6908:EE_ X-MS-Office365-Filtering-Correlation-Id: dd2801b9-014e-49db-b9f0-08dbbf74c112 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JDJbs2rji10DVtUyMV8n3sSgQBvJY+gt6rZ5gUL1L9qi3OxDyC3X56Nr+SPgfDLq65U4KzD86ToCdzkVKiOyCZf7NA+Plfi5c9lj3waVTT8IsgMC0UYlyB3euYqqSqxugBSWlMrzqN4vGPj2ueVB3bhEu4DaFXOjFJVjP80PXU7yzX0lG8FrUKGwIy9U+tk+ES1+JV04lfCCicR1nVGl8bIe/MkFuMUAwCLe9hysgPSaXJ4LCX8STMl5i8OrlRyJXlaTnhZK9Umj/HSH8JYxKg04koNT8bbY+UnZMw9KHUs2tKz+0HEmp4ap2bgPi4KRixALoPbTRx3Adw8RqguHf1PqZp9fo4ZCl8Cn6+qEsI6bFnN97TqJX12yDehVv5g01tVg0S4cdZF6rg8dwSw4/RW/0sYaDplB5Zv2vwzzahCQXKHLqCnfUH3q6Sx1BEgTWjYbO6WXP6slegvt5O9LIo/xvQyo1MdVq+MTKqXjJKJoVRGmhVGEnkTyK+W8EgG0fAqzLbMoHYxaRAf7RHKbjmGOrqTM/rcLrHNpVyPTiqeV3eTfwdjMrEG/KRQpQffDDpISFiAOX8MD4IGikFmJfX0MYxlKthB1VOzHxzZVYf3Oi9FnAHmTAYxncZRynedfttvcqM0tWDKvClybZQGikfyKK7HsqSx03vLPctclyf8= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(136003)(376002)(366004)(346002)(39860400002)(396003)(230922051799003)(1800799009)(451199024)(186009)(4326008)(53546011)(8936002)(6506007)(6486002)(478600001)(6666004)(66946007)(41300700001)(66556008)(6512007)(2616005)(316002)(26005)(54906003)(66574015)(6916009)(30864003)(8676002)(44832011)(5660300002)(966005)(31696002)(66476007)(36756003)(38100700002)(2906002)(86362001)(83380400001)(31686004)(23180200003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eGl5elVtS1BYUzhrYnBLOTNZM0pBeW4xUnZDemhNTFRZUVJjMEZEbzN5UnR6?= =?utf-8?B?MnRSTFJrVkdXc3dmQWpvcnJZakhrQzBBakpJZkdmMTZHR1pJdmR2WjBPUno0?= =?utf-8?B?ZnVtR0REdzlUTXQ0cCt2MEVUSVpGRy9QZWVUOTlzR0E2UTNvMEVyOU5seVZq?= =?utf-8?B?ci85Vzk4RVhQSytNY2pzbjlxN1R1dUhldWdScXpxRDk1VVQrQmZpRG91V3N5?= =?utf-8?B?bnQ3ZEpaOHR2VE9nQkhlQ3JqdDdpc3VYOFU4UkRWSCtpWTRodFRRNGpIYUtP?= =?utf-8?B?czdETkk0MHhlZHYzbDJsT25jd2JIN1BFcTRuVWJ6TWZ5L28zai9yRnNEMjRa?= =?utf-8?B?UmlDWjkzdmIzZjBUSFlzYVZ2RDZlQVY3aWZudkI1RGdHUVFkaWVMVlh2c1JN?= =?utf-8?B?eHlTV20rRUx4Q3A4eTFxYUdqdEpMQ1pBVGUxVUJqWnpBRXY1WEhxMHNWRjBL?= =?utf-8?B?T1IrS2NlZko5VDQ1dy9RdmNqZ0tsUGxxRzZEVmFZTlV0TEFEclRNeUFZSndT?= =?utf-8?B?cG44MGpWWE9MZHpCR1pPZjM4cERmWEptM2xSNWp3dDhpQmN0b1ZPa0NuVHcz?= =?utf-8?B?bkhhMmI3ODZ2V0hlU0k4UUx5MzgzbW1vZHRWM1E3M2hLcjY5WkxDNktZQjB5?= =?utf-8?B?MzhIWU9jUEZselNiU2VIZnFjN0lIS055ZmZKM1c1OGtrZlIxeFBETXNvVXgy?= =?utf-8?B?QlQwN3Era3hHQ0JQVVR0RG03eTZxNHhxdEFlT243UFRsTWtIeExaNjFCdTdL?= =?utf-8?B?TXZ6bVdpb0wzYnNzaVhTZkRrYkg1Z3ZUYVJPNDIyVGsyZXhxdUFpZDVPV3c1?= =?utf-8?B?clpIV0kxTmFVWmtINVJFNDBEL0tHYUIzRWgwM1pjODZ0L0FVTm54NzIrcjZw?= =?utf-8?B?U1FRcWVOYm9LNFUrM21BZEJ6Tm0vdmVoSGhveVJtTnhNRjBrOE14ZmZDK1Zs?= =?utf-8?B?T2JvN2Q3RkprdGlzZElwN0U4MGQ0RCtzZVhSZjVQSnNqSjM3UFVJRGhrR1dM?= =?utf-8?B?eHp6TlpHckNzMHJRVmdLT0I5RkF6NXlTS3MyWHF6NVVxWEhiSkxpZnlCdys2?= =?utf-8?B?UU1VNm83MzNLNXBWeDc3bzZ5MlJsZUV5aExKQ0p6aGdTTjM2VjVtVUJRWGU0?= =?utf-8?B?SFJ0U0JjZmo0ZWFJZjZNZzltcWpVN01zdkRtZ3dOZEwrN3VvSUZLYUNZMUgx?= =?utf-8?B?azBzQm9sdzIyVDhuWVJST0cyTWxxNUpFS0NaZUpzektRRkI1R2NFRERBTjB1?= =?utf-8?B?SFBoOFBxMVc3c3AvNmpLa2JMNjZTdFFNQ1I5TG8yVE1sSGlsQ2NzRlZFeGZL?= =?utf-8?B?emlMVVJBZGtMaTZpODMyQXJKZ2dTYTlhWm4rMjE1S3N0QVprc1E3b3RLelc0?= =?utf-8?B?TVZFWTNPOXYwWmtUTzFSZXZKR0FJZkh3L2gxeklPZTJhWURHTGJiY21mOGNP?= =?utf-8?B?V2ZMSFkvVmFvL1E2WmU3U0ZOallrQU0ya1NyQlhKSWYrbGlIZWRKSGxrNE9H?= =?utf-8?B?TGd6SFlRd2xZWVlyT2pnSkJUNE5TQ2FqV1krcng1OFJVSm9LMGJid0VTeC9k?= =?utf-8?B?MUJyZ2lSSStLQ2t1NUlHK0JibDZhRG5HaVRiSUU3cjhKWTRWVXBpcUlNYTNv?= =?utf-8?B?bjFubmpWbzh3V2VjallvMGpRRWVicEx2U0hvVU1CQlFOcVZnNnF3ZmM0UER3?= =?utf-8?B?VUZRdzVocGt6SldHaENPd3lCNUhGTUZqbVZPc3grVkRFVVprUUdtSEpQSHZx?= =?utf-8?B?UnhiTDBvWVJKRlg4M3BHdzVXMUdCWTJsT3RCeW9nSWNJdEVEUEVHd0o1cWRs?= =?utf-8?B?VjN5cnpLU3JCTjh3cTYxaXhqcUpEdE9xMVNZMm1TaWwzWk5aODE0bUNXTDdK?= =?utf-8?B?NkV2VzZvN3JjWi9KaldMVFpNdWx4d1JsYjdQd3VNaWhweEtlUHAyTTJRUzZK?= =?utf-8?B?bzVRRjZNM0Z1ME9PcjhIWG9keEhIY2VUUnhvZS9vYUdBWDZXcm9MT0g0VDcw?= =?utf-8?B?bFBKR0JkanZSR3pJelZHR3BBSkRkNFJNUVdGVGVnT1NPQkMxYnM1NEZ6WW9m?= =?utf-8?B?MkJtNnROVGEyZVZ5K3ZPQStFWVpRYy8wd2dMMW5RZE1QSFRZZGdnSW40YTU2?= =?utf-8?Q?Nix1HgA8r5pNQSB0ArPGDKZpR?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd2801b9-014e-49db-b9f0-08dbbf74c112 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2023 16:13:58.3711 (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: lghESDpPP2v55L1H0xTyTDvUCtShJK8T84Kd1/Vmuo0TGdEDwvMwEXJgCKCPUBwp X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6908 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 9/27/2023 4:03 PM, Stanisław Kardach wrote: > > > On Wed, Sep 27, 2023, 16:09 Ferruh Yigit > wrote: > > On 9/27/2023 2:48 PM, Stanisław Kardach wrote: > > On Wed, Sep 27, 2023 at 1:55 PM Ferruh Yigit > wrote: > >> > >> On 9/21/2023 3:49 PM, Stanisław Kardach wrote: > >>> On Thu, Sep 21, 2023, 15:18 Tummala, Sivaprasad > >>> > >> wrote: > >>> > >>>     [AMD Official Use Only - General] > >>> > >>>     > -----Original Message----- > >>>     > From: David Marchand > >>>      >> > >>>     > Sent: Wednesday, September 20, 2023 1:05 PM > >>>     > To: Stanisław Kardach > >>>     >>; > Tummala, Sivaprasad > >>>     > > >> > >>>     > Cc: Ruifeng Wang > >>>      >>; Min Zhou > >>>     >>; > >>>     > David Christensen > >>>      >>; Bruce Richardson > >>>     > > >>; > >>>     Konstantin Ananyev > >>>     > > >>>      >>; dev > >>>     >>; Yigit, Ferruh > >>>     > > >>; Thomas > >>>     Monjalon > >> > >>>     > Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration > >>>     > > >>>     > Caution: This message originated from an External Source. Use > >>>     proper caution > >>>     > when opening attachments, clicking links, or responding. > >>>     > > >>>     > > >>>     > On Wed, Sep 20, 2023 at 8:01 AM Stanisław Kardach > >>>      > >> wrote: > >>>     > > > >>>     > > On Tue, Sep 19, 2023 at 4:47 PM David Marchand > >>>     > >> wrote: > >>>     > > > >>>     > > > > Also I see you're still removing the > RTE_CPUFLAG_NUMFLAGS > >>>     (what I call a > >>>     > last element canary). Why? If you're concerned with ABI, then > >>>     we're talking about > >>>     > an application linking dynamically with DPDK or talking > via some > >>>     RPC channel with > >>>     > another DPDK application. So clashing with this definition > does > >>>     not come into > >>>     > question. One should rather use rte_cpu_get_flag_enabled(). > >>>     > > > > Also if you want to introduce new features, one > would add > >>>     them yo the > >>>     > rte_cpuflags headers, unless you'd like to not add those > and keep an > >>>     > undocumented list "above" the last defined element. > >>>     > > > > Could you explain a bit more Your use-case? > >>>     > > > > >>>     > > > Hey Stanislaw, > >>>     > > > > >>>     > > > Talking generically, one problem with such pattern > (having a LAST, > >>>     > > > or MAX enum) is when an array sized with such a symbol > is exposed. > >>>     > > > As I mentionned in the past, this can have unwanted > effects: > >>>     > > > > >>>    >  https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493 > >>>    >  > > >>>     > > > -1-david.marchand@redhat.com/ > > >>>      > > >>>     > > >>>     > Argh... who broke copy/paste in my browser ?! > >>>     > Wrt to MAX and arrays, I wanted to point at: > >>>     > > >>>    >  http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR > > >>>     > TsUw@mail.gmail.com/ > > > >>>     > > >>>     > > I agree, though I'd argue "LAST" and "MAX" semantics are > a bit > >>>     different. "LAST" > >>>     > delimits the known enumeration territory while "MAX" is > more of a > >>>     `constepxr` > >>>     > value type. > >>>     > > > > >>>     > > > Another issue is when an existing enum meaning > changes: from the > >>>     > > > application pov, the (old) MAX value is incorrect, but > for the > >>>     > > > library pov, a new meaning has been associated. > >>>     > > > This may trigger bugs in the application when calling > a function > >>>     > > > that returns such an enum which never return this MAX > value in > >>>     the past. > >>>     > > > > >>>     > > > For at least those two reasons, removing those canary > elements is > >>>     > > > being done in DPDK. > >>>     > > > > >>>     > > > This specific removal has been announced: > >>>     > > > > >>>    >  https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493 > >>>    >  > > >>>     > > > -1-david.marchand@redhat.com/ > > >>>      > > >>>     > > Thanks for pointing this out but did you mean to link to the > >>>     patch again here? > >>>     > > >>>     > Sorry, same here, bad copy/paste :-(. > >>>     > > >>>     > The intended link is: > >>>     https://git.dpdk.org/dpdk/commit/?id=5da7c13521 > > >>>      > > >>>     > The deprecation notice was badly formulated and this patch > here is > >>>     consistent with > >>>     > it. > >>>     > > >>>     > > >>>     > > > > >>>     > > > Now, practically, when I look at the cpuflags API, I > don't see us > >>>     > > > exposed to those two issues wrt rte_cpu_flag_t, so > maybe this > >>>     change > >>>     > > > is unneeded. > >>>     > > > But on the other hand, is it really an issue for an > application to > >>>     > > > lose this (internal) information? > >>>     > > I doubt it, maybe it could be used as a sanity check for > >>>     choosing proper functors > >>>     > in the application. Though the initial description of the > reason > >>>     behind this patch was > >>>     > to not break the ABI and I don't think it does that. What > it does > >>>     is enforces users to > >>>     > use explicit cpu flag values which is a good thing. Though > if so, > >>>     then it should be > >>>     > stated in the commit description. > >>>     > > >>>     > I agree. > >>>     > Siva, can you work on a new revision? > >>>     > > >>>     David, Stanislaw, > >>> > >>>     The original motivation of this patch was to avoid ABI > breakage with > >>>     the introduction of new CPU flag > >>>     "RTE_CPUFLAG_MONITORX" > >>>    >  (http://mails.dpdk.org/archives/test-report/2023-April/382489.html > > >>>    >   >). > >>> > >>>     Because of ABI breakage, the feature was postponed to this > release. > >>>    >  https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/ > > >>> > >>> This test is flawed, reason being that the NUMFLAGS should not be > >>> treated as a flag value and instead as a canary but this test is not > >>> taking into account. > >>> > >> > >> Hi Stanislaw, > >> > >> Why test is flawed? > >> > >> The enum in in the public header, so the 'RTE_CPUFLAG_NUMFLAGS' enum > >> item, and there are APIs using the enum, so the enum exchanged > between > >> shared library and the application. > > In a similar way lots of Linux uapi headers contain bits that should > > not be used directly, even though they are defined there. The reason > > for that is the C language syntax, not necessarily the intent of a > > developer. > > Since NUMFLAGS was a canary to make the flag handling code easier, it > > should not be treated as a "real" value and hence my suggestion of a > > flawed test. That said, NUMFLAGS does not bring enough value to not > > remove it. :) > > > > Both it doesn't enough value to hang on, and we don't have control on > how it is used by the application once it is exposed by the library. > > > >> > >> Similar thing discussed before and when enum exchanged between > >> application and shared library, there is an ABI breakage risk > when enum > >> extended and general tendency is to eliminate the MAX value to reduce > >> the risk. > > Agreed though as I have mentioned before, "MAX" has a different > > semantics than "NUM". Then again since we have rte_cpu_feature_table, > > we can RTE_DIM to check the user input. > > > > Their usage and intention on having them is same I think, can you please > elaborate what is the difference between MAX and NUM enum items that is > added as last item in an enum? > > MAX specifies a semantic numerical value, such as MTU. NUM counts > elements in an enumeration where elements describe some items and their > value is just an implementation detail. > > Ahh, I see your point now. Most of the times, in enums, last item with name MAX is indeed used as count of elements more than maximum semantic value, and sometimes LAST is used for the same. So we are using them interchangeably with NUM. I agree, for a MAX value as you are referring semantics is different, but the one mentioned in this context is not an instance for that case. > > >> > >> > >> When enum value sent from library to application, it is more > clear that > >> this can cause an ABI breakage, because application can receive a > value > >> that it is not aware in the build time, which can cause > unexpected behavior. > >> Simply think about a case application allocated array in > >> 'RTE_CPUFLAG_NUMFLAGS' size and directly accessing the array > index based > >> on returned enum item value, if the enum extended in the new > version of > >> the shared library, this can cause invalid memory access in > application. > > Using the NUM enum element (which serves as a last item canary) to > > size an array is not a good idea unless it's returned from a runtime > > call. Otherwise one hits issues that you've described. > > > > I agree :), but that is a way to describe how it can be a problem. > Also last time I argued similar to what you said, that application > should check against MAX value before using it but I have been told > not to assume what application does. My take from it is, expect worst > from application as a library side developer. > > > >> > >> When enum value sent from application to library, I am not quite sure > >> how problematic it is to be honest. Like being in the > >> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' in question. > >> Only when application sends 'RTE_CPUFLAG_NUMFLAGS' to > >> 'rte_cpu_get_flag_name()', it expects a NULL returned, but this won't > >> happen in new version of the shared library, not sure if this can > cause > >> any problem for the application. > >> But as I mentioned, general guidance is to eliminate this kind of MAX > >> enum value usage. > >> > >> > >> And for this specific issue, although usage of the enum in > >> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' APIs is not > >> clear if it cause ABI breakage, > >> enum being embedded into the 'struct rte_bbdev_driver_info' struct > >> doesn't leave a question, since this struct is returned from > library to > >> the application and change in the enum causes an ABI breakage. > > Enum size does not change irrespective of changing its values. So > > size-wise it's not an ABI breakage. Re-ordering values is an ABI > > breakage.> > > Agree it is not size-wise issue. But still an issue. > > > >> > >> > >> Briefly, I think even appending to the end of 'enum rte_cpu_flag_t' > >> cause ABI breakage and removing 'RTE_CPUFLAG_NUMFLAGS' helps to > extend > >> this enum in the future. > >> And an outstanding deprecation notice already exists for this: > >> > https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst?h=v23.07#n63 > >> > >> > >>> Your change did not break the ABI because you have properly > added the > >>> new flag at the end. > >>> So I would ask to change the commit description to mention that > NUMFLAGS > >>> is removed to: > >>> 1. Prevent users from treating it as a usable value or an array > size. > >>> 2. Prevent false-positive failures in the ABI test. > >>> > >>> Also it would be good to link to the aforementioned ABI test > failure to > >>> give readers some context when inspecting the git tree. > >>> > >>> > >>> > >>>     Can you please add what exactly needs to be reworked in the > new version. > >>> > >>>     > > >>>     > Thanks. > >>>     > > >>>     > -- > >>>     > David Marchand > >>> > >> > > > > >