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 A283F42653; Wed, 27 Sep 2023 16:09:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 80C7C402AA; Wed, 27 Sep 2023 16:09:42 +0200 (CEST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2085.outbound.protection.outlook.com [40.107.94.85]) by mails.dpdk.org (Postfix) with ESMTP id 073C54028C for ; Wed, 27 Sep 2023 16:09:41 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aOaQDsdj8EsJLqGP6K5Mn7LCYMc41Qe3BcgsIrRjBkagKWKy9/3OK9VucFkFeKxIHIIcW0h7i45NF5k6ppzazYxAShv+5gK1ZBQuRozhBu4fTCL80wcjHwMojqAvSzlsocxSFWVzaOGxzr0/cRCBa7xQZ6aNLaN6FPxUIN/A+00AZgqKx/yl4+3hkp1AwadLjVC8fiKRKlqtUC3LAt/rbNrj7AgwNIeWwvyqT7j2XZH4vJnBDAG0D1pFwKMO3wB1fRngrskFM7NPfWpuWdpyeNuyk7OTK+c1A4sLBObglVBMWvbMPYJeVvzHmZU1OPsYx/HJJFR3i16saCQ12/8DEw== 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=i5VpAowN3j7I9NeRNeCH/YGQvnJxXCdJPaV2CCIbG1A=; b=SAVRuwrPOja64pNS5N6H7IM7rXeVv7prOtNaojxktvCy/2L44ZwLoPR/Bgd+cTdMFdgA22euwT53QGLLfYizzu7dT1mg8XZlL4cXmjRWG5EJivSgxXM23GiGZRE//vdgwxMB+4gk6kdiWVh0ArxwKoAzVE26HqL9lrnnG2W+pdzUKpfqm2we5/Ipybx9+rYWDuf9ggxZg8ZSR2S+9CuHBpkDknI3ZlxOnZFiC3L4wujCZmVZQGZyz6SGu7A636ik9SOndxX/2NyfQzmE7PcYGkEIMx/l+k9W3WLWvJcgUjHNSjxTJF3De928FQrlvFuTWHLjn1XJrcKRnRyEOpXq0g== 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=i5VpAowN3j7I9NeRNeCH/YGQvnJxXCdJPaV2CCIbG1A=; b=GouV3NZbqudclCQw9FdjSfrhvvtSiHlxMfcu88FsTdhA/oN5S5/ngWq6CLaMJnT9rMA+t35/O6VCLI2G/nxImV5GwVxbQwMtFHAa8Za0SD4GVaDEKDhUowsUt/tJ+jobFU1ClxH/olCRuJRwarjqlOovQ9WmamRTT+1Z4k1N/qU= 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 PH7PR12MB5620.namprd12.prod.outlook.com (2603:10b6:510:137::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.28; Wed, 27 Sep 2023 14:09:37 +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 14:09:35 +0000 Message-ID: <6434ac72-0f5b-450b-900d-e34078756355@amd.com> Date: Wed, 27 Sep 2023 15:09:29 +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> 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: LO4P123CA0327.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18c::8) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|PH7PR12MB5620:EE_ X-MS-Office365-Filtering-Correlation-Id: f0b5873c-9458-4144-de67-08dbbf6360c4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Yyto4CERunWUwI0izjuJCCS0tAeLZJiOcR+KCWXCCER8q9xzzgSKqubpn0TY5VljPatGUSRKXqcLzehWvjM2Gk4liAkGOGZb/vABdX+5HVYU/Ieh/6xV04WQGiKjsGzioPMx9M7C05B8G0L1001s6QGenWz8qflH0xRrkcxZms60syA+3yC7/kpCjn4TrSU1j6uOR5T9gLVjEfZzzIg4IKY/b5j3eDpAB+4Ueqk8Y21ZKf6frihyebC/phABDjvbCKmnONCmRhGx+9a/9dbNnp/pkFwAceMdjWfFrjzdn109RfomIwD77QPkB/qO54W44JzY+WtL+y49Hv+nyEaR0OBO8HsQMo34/tUwnv87uUlTZLWRo7PTjckipWRQCLEmsw9fvmxKZnfXZEM5EH39U4EvK1uo93sv0I1tsWO2d1Lz2mso2vqs5n9OquiKzkDYIE1L04yn2Obxr1qy5diifC9sCA79TcG4r45LU88lcxEOpce+0nv6uZL4HiJkKEfapfIOzJYdC1h8+Hx9zMIO+za2lVClWSdBzpFHd382HrQ9mVaLXPlJkkO8HHN2AdvWMIWlKLxYmLuG9YC5l2XxCVEA1K1XwVXsXqYcWWAfXJ0D4uvDFHAxWUdHFHmgQoicrAekWWKBkqX5x7Qb4itCUJaxO6wcyNeTON6Ll41icNI= 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)(376002)(366004)(346002)(136003)(396003)(39860400002)(230922051799003)(1800799009)(186009)(451199024)(4326008)(6486002)(36756003)(6666004)(478600001)(6506007)(53546011)(8936002)(26005)(54906003)(66574015)(966005)(6512007)(66556008)(5660300002)(66476007)(44832011)(41300700001)(316002)(8676002)(66946007)(30864003)(6916009)(86362001)(83380400001)(38100700002)(2616005)(31696002)(2906002)(31686004)(23180200003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QnRZTzJ2WDc5aU95Qy9vQTRtc0tlZzdEaWh5cTAydUk1WW9oMHVBSVVJMFBK?= =?utf-8?B?QW9NdGFMQWJVNHFaV2dyRlJnRUxGYXIyWGI4SjFUa1hxK3d6WHpMZDA2anpu?= =?utf-8?B?NGR1cUNhV3l1anNKWlhZMTZNOXlzMngwTjFUeWVZblBmUzNEbnJVcGxFVmhE?= =?utf-8?B?SHBQU1FRMmhEbTB1N3N6ZEtzM0tEQ3hrYlIrMy9zZDJmSlZGSlpDRDRmMlhN?= =?utf-8?B?T1dZdGZBeXNPT0MvRi8xVEhveFJvME1EcWQ1aG1naTllVmF2NHpzQXZCSCtK?= =?utf-8?B?aXo3cG55S1h3blJKdmo1UjNocHIyYzBJVlFOS0dKUlFFQlhuUGVmcVdEQkFQ?= =?utf-8?B?MGFBS2czTHdmTkNuTTBlNkxTZ2FzMXpSZ0NpKzQ4VFBSTlBZb2VrNmwzT3Rv?= =?utf-8?B?TjAzY092dDlvS29xMGFCTlRHUStZY2d0NjdiR2dUbDRBNHN1c2NkZkUwUUJw?= =?utf-8?B?cXdRVWRTZkNEMmtuVnZ5b2NBOVRhdTR1bmp1VW1RenE1NU5udjZyWmp3YVdt?= =?utf-8?B?Zk9jaitrZUZ1Zm9KOW9YeXJveVZ3NWdzVW9BNGU4T0tOOHJMa21TVzdEbEJ4?= =?utf-8?B?TExzRldzdVc3UmFyUnAwZk96ODk3N0R4NU5oSDFLWFMzck1xc1FOWWJPTk5Y?= =?utf-8?B?ZHh1TU11YmQ2bTZjSXh0U2Q5d3dtMzVnQzJncDd1TU1uaXdqZFRmM2kreGV2?= =?utf-8?B?Sk9hbC9kN3JHVWtlZlRadjQ1UTkyRjRKN3R6V25MRWhFR2srT1dTaXpSckFm?= =?utf-8?B?djFWb2Q1a1VqMjF5OHpRcGZTak5YS3lMc2lpSEw3VDZnM0VGaWFMdVZ0Qmo2?= =?utf-8?B?Tk4zS3QyQW45Vjd6VUFkZHFCY1BYMUhaMmxuWkEyVEl1d1BJMGZYY2tWalRO?= =?utf-8?B?cjZnZnl3cG03d3k2cUQ2T3lnenpmRml2R2F1ZjFVVE9ZQ2hiWnhOejB0MEpx?= =?utf-8?B?NXN1UlM0UXZXMDI2MWZwYzNJUkYzV3VReWxDRy95aVFNdUZBdE4wQ0lhNUl1?= =?utf-8?B?RjVQM1phNS9HWHFyVkxjRDhYZ0VZRjdjczc0UXFsZy8vQ2orT3F3cURjRUlU?= =?utf-8?B?OEFRQ0Zxa1laakN3U29BMk9ldlFjcVl2OFBJMElPNHQyaHg1cDdUVVhacWFr?= =?utf-8?B?NWRIMjRFUUlUVUI5UXM2aHBpREtoSUk1RWVPNitSMit5SFZrc1VUS05qaFZo?= =?utf-8?B?bWc0MzZvVnBLaE9yeG9DenVsNVpha1FzU01YZERvYVowNGFtT3ZUckxXQmh3?= =?utf-8?B?QW5CVmF4TEllL0FkOE1LSUQyL04ya3Brd3NsM21zQ0xJZVZLZlRoVGxNTlR1?= =?utf-8?B?Y2taQmY1bW5tVEF3OGVBbklnRTF0SmJ2WjAvUVd2K2FQTThzeE5Mc1A5UmpQ?= =?utf-8?B?OWhuUitZR2NlM2xJZ3RJUis4YTVKS1RIVURQdGNFdjh2Y3FGSTZtYnNzdS9F?= =?utf-8?B?TmJZNGdBeHZ4ZjhpbUl3OGZidXYyZDVTajJRRkh6T3UvejYxVTdsOVM5b2lW?= =?utf-8?B?KzZzQ3FLWGxiTzk3Zmd4K2t3SDhtSlJiOFEyRlhyYmVzWXBKWS82RUErdGJ0?= =?utf-8?B?eGFjeElsTGJyQVJqVE5POVBKWkFPSkVJWTBiaVNkek5qNHZaMXRpd2M4QVdT?= =?utf-8?B?Znp2SlRzTERCSHRsdGFKR1lKaVR6emFaZVlNWmFvQW45L2Z6Rit1Tmp4U2tm?= =?utf-8?B?REJiM3NYMndFa3NZa29xeXNsbnFuVFplMWtOMEUrbW1ZUVlaS1JKTFFQenVH?= =?utf-8?B?c0pJRWkybERJTXUzVlJIMTlhMTJHcTB6ZkpoZVZ0UlVpZjZQZ2hKa1o3Q0lx?= =?utf-8?B?MGhmNzVhWGdWNks5VmVLZkEzSVNjUmp4TTdDZHlGc2MvR3F0UC9PR1dXTDNa?= =?utf-8?B?YnB2eG1kOEFJYmVDQTM1UjdKaDVrK0FFb2JxVkhqa2dRbllQV29IN1AwYndo?= =?utf-8?B?WmNHbUhFQjNMc1lHMFp3bkhoRXUydXBjVW01QUdKMjY3RDdvRmVmcnNQV0lu?= =?utf-8?B?OWpaQ1plQjhvWVdudEdKMHZ3REJ4VkJrb3Q3c29RZzdMT0UrUFRIRHo5Slox?= =?utf-8?B?T0Nqa2ZNQmRMalM4NFU2WnZoNlZmRXFhdDA4UEhEVGNXZUVoLy9PaDcvdFNh?= =?utf-8?Q?pXpDLEpQJXxTNotnUeXfMrRLD?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0b5873c-9458-4144-de67-08dbbf6360c4 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2023 14:09:35.1953 (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: UJYxqLPpLJ2um2ljlLPcgPb0Jf7njhn88FbisySstOvb39Y++mJ6F44lgw2qvWON X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5620 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 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? >> >> >> 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 >>> >> > >