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 CA19A42651; Wed, 27 Sep 2023 13:56:01 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F182040A75; Wed, 27 Sep 2023 13:55:58 +0200 (CEST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2040.outbound.protection.outlook.com [40.107.236.40]) by mails.dpdk.org (Postfix) with ESMTP id CE526406B8 for ; Wed, 27 Sep 2023 13:55:56 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EcGeKjKbXdmaAFPT0R/6VI7owjhbqn6hdS880eWTHW0dHCSGljGai8IaZVyVgmanT3gxFfRSgGhD+zshh7QjDSGUPrFRraSNUCrSC0pzx6YRU9roPFdBc+JHbkBLdXHKXxGeXd8zF80/HsogyjRRAnXpkPlhzdWcw3Il75E3PwH4ieFhISZyAmoxT1xkyWGNWEbNJ1GSNTo0beqnXENhYI+sAhKwzp91sHEGCOJISLW+sk723i5SFcYH/c4fxJbNyODy6RaQTLWVX+4A0db5aJTsAsPczccLXibZY4+vKP+NHk9reTZlVy6upf7sjQ70uklOROGIUdCSJzTE8lCjmw== 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=rv4YPIAErxvBN4y/epeJrm7qKly1pau1HuXS8kzBMPc=; b=akVRp/LwBLJKB8vnGG93dhc932n9F7GZFRrWuNWmP9K2V4O/xOGutVb9DtIBh4dgZF5W20aL+2aEtDxlXqnfzqWLTjI2NMUl/M9JdVEs0fC89Hgld7q2JV2z56CSifAcJq/g5qvu9yR9onsILookO/gqlshn12f0AJhlSnsjmgbt3GJDTDyG82RQoOl5NsXr6GUBEP3LNEE+Q02N4+mbUC709BkwnArWIlRtaLj9FWJZSiXlYDN6PH6RP2UqWBE6F5kEGnRCTJw4sPHnUZMi0WABT5LH1+j2L+hUtVLYjF1CKNutSGnjctfnGoUjp6E/AdYCt/k+PZjUuoWKKTdSBQ== 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=rv4YPIAErxvBN4y/epeJrm7qKly1pau1HuXS8kzBMPc=; b=BGJAFk0fqu2iudHUJIKjN1tGc/k7mtjYDdug4gfee+D1lTGXgfvFyoH5YhIci6kU+JpESuzO1eF6ADYrW7g2y/3nd5v39LMoY/2YxhLfOGH/FlHuG8luQc7imPcRU0Mr4aJhg/CfFtq+RazZ9EEh3w+h4lr96MEnsJ4rqXFAuI0= 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 DS0PR12MB7701.namprd12.prod.outlook.com (2603:10b6:8:133::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.23; Wed, 27 Sep 2023 11:55:54 +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 11:55:54 +0000 Message-ID: <530da851-fcf3-4dcf-8f51-e11e9784763b@amd.com> Date: Wed, 27 Sep 2023 12:55:46 +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?= , "Tummala, Sivaprasad" Cc: 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> 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: LO4P123CA0259.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:194::12) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|DS0PR12MB7701:EE_ X-MS-Office365-Filtering-Correlation-Id: 6004371e-00bb-46c2-e7e8-08dbbf50b3e1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: r4QWDFCpzcEDIgyILTZaGqRvFZ3mcvlMZv/gy8PErYEUxVbHaV9JYUqEfuW68PUNqup6oD2GdeVjebKhPIA84Zapscj2OW+TVuoGX2uzjfQr3SCv++DYaLFrCYS+fF5AqSmbLbbqizULVPzg7Yyu+me8AxCT5bJeBbsF/laI0P9ERO0g/Y9+qBD1MTrMbjwFz1V2a/BAdk1o4n95LRTxPIfuwAZ8tGBozSZHT9BQVnHcIwMnrjIK7u8tqzxAUGJCGyroS5dVHcai0XC00TiIwd0dgJNMJsmyMm0go5lrFcl4OWmydtMCGybJRAIwXu6j7o59dC8yzX/MU8ycWiKk7tTIemnc6c2nf0Re2k0Zc6lIJiRENCXWb2JGNpv8l/HnKiLfxh8npPeI7jstpO4s5XiqeJJxWE/JAAdLQ1RtIyW354SsVG4JY1mh/MZXBS1n3wrhNwsE8oKsgYQbuIJCX9FyuXK3QCa1POzl5Tk5GMBjdhlGaKNxbieBvuiGS5VopI4TzpVKkS5cHboh2t08LpfZ2x3380bVu1IgjvKG728iIWusKBpM021Pq5LGFn48C39l3AOiqsE4f6Jtq1Bjp1IS3XXUZxgwuoQcdAbtWBxsJlRyZ59v9cN9gO6umNiNpxAFqHEyeqgQdCZ0iI+slGN67JZ3uDMnB7Ov9fcKmAU= 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)(366004)(136003)(376002)(39860400002)(396003)(346002)(230922051799003)(1800799009)(451199024)(186009)(8676002)(6636002)(44832011)(53546011)(8936002)(6506007)(6512007)(316002)(31686004)(5660300002)(54906003)(110136005)(6666004)(66946007)(41300700001)(478600001)(66476007)(2616005)(6486002)(4326008)(66556008)(66574015)(26005)(966005)(83380400001)(36756003)(2906002)(38100700002)(31696002)(86362001)(23180200003)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NEkwRlA0TFR4TGRackE3VExPci9Hc0lVT3QyS2loZG94NjRmaGNvbE5kazdK?= =?utf-8?B?MDYydjNpQmRlLzlOTnFNQW9aMWZ6Z2t1QXBmS1dSS3JXcHU3Z0MzS0pKZWM3?= =?utf-8?B?Y1NwUEN6aHd2ZUF0dTZZNVphSkRVZTgzYzI3NjBzK1E1cGgzbnU5WGtqYmVC?= =?utf-8?B?UXczcDk0VWVYc0hNSit0UWhGUGJKTlJsYXhVNjdKYVNPZy9kOGwrbFIzRlJ0?= =?utf-8?B?Z0ZpUHYzRWNsWDU5MElNT2FJVVh0UWhuendZY3NhYXVhQTZYeExqbWtpOXJ4?= =?utf-8?B?NVQydHJpblVYWktFWXQvVkkxMzZMWmV4QmZRa3N2WENMbmM4U3MycDZraXRq?= =?utf-8?B?Vmt2QThDbzRNckZoemFJKzdSQ2xKVCsyaTRCYTZZRS94My8wSlB5ZFkyZ2N6?= =?utf-8?B?RkJ2aHpYQlBabmR5NnpuL3Z0YjB1aVBxRnEvWU1xc2hHd1I2M2xJNEJDVXhy?= =?utf-8?B?VkNQQXN6Y3gvWVpLRjh3OWtNNkhhZURlQkQxbG1jWEhuaDhRVmtGWUZKRDhS?= =?utf-8?B?UHU1WTZlOHRWZVV6NW1XSmFSWkxzYnl4WWVBWm56dndIa0lLUWU5dG5rWDZY?= =?utf-8?B?Tm04UG4ycFg4dTQ0QXJFWWpMeWhuL2E0b0RORXk2eVVkQWJwZW1MTmtTTGNS?= =?utf-8?B?YlpUeUJEYVZ5S2tIR1R5Mm52S0FHZEVFTndoZWhjWkc5N2VQRTVHM0tzY04x?= =?utf-8?B?SGlsOHl5V3BKeDNPSU5ZMnNUeE4wcmxaaTFxL3dKbnpHVFZScUs3eWZVZm9R?= =?utf-8?B?ekwrV2lteG90NzJSbzNRK0Rva3p5Ni92Mm5JMlVOS01HZUtkaCt4b3hJT3Q2?= =?utf-8?B?bkZVU3RZYlUreWtQZjQ1RThJSW5NMzJjbDJIQ2x0aFpxd0Y2WHp2RkRNTkxK?= =?utf-8?B?LzFxQVRZU3YwTlhodVlBNVpJSWl0eElaRmZUSGxVT1JjeEJNWmpkK2kySU1D?= =?utf-8?B?MytLVExOQ3hIbmxkeUY0V21EcEZDby9KOEE0MlVBUXJEdm9FcjVxdVV3eDRu?= =?utf-8?B?a3VYNnhZV2dubTBhZ2dMZEdCY1hZeVpKVmNpOU42bGFFRi9aOWJTS0dMMkU5?= =?utf-8?B?NUpQL2IrUUZncTVGcWFHK3pGZUVrellqUlQ4NmdkNE1RZkd1UUI3U1B3VXM0?= =?utf-8?B?WllUMGVmTFlqclpqdUFNQXBjRjVYcTVmb09ndEZrelh4NEZmVWFwbVJxNU1m?= =?utf-8?B?M0ltaituSmhERHdIR1gyWXpESGltcEpUOXBybVNjZmtEWExBaTFMRElPTnlI?= =?utf-8?B?RkxVZ0xCS00wUUxNa2JkOS94RmtxOTRyak94a0tkQVA5UjliM213cHk3bUFl?= =?utf-8?B?YWZ3V1JnUnNZV01OT2Ixc2plb3lNRDlMcGhUdzdHRm0xajRhTDM4YlRMTVA4?= =?utf-8?B?KzAxS0k3RU94REVKZFY5bjdQSnZ2TWk3STFDbjlSTThzazhQVHJYWlZ5QzhE?= =?utf-8?B?YnoyZVd5VFd5REFZNU9qcTNoZ2VXMDNDelRobFc5MTh2OGhFU0xRM3Jyd0Rn?= =?utf-8?B?aEMwcysrazY3TWhMZEZmNEswSzlDbXZGSFA5R2VWU0NmZm5LWUVjWEt2U1JC?= =?utf-8?B?U2ZlTGVYRTBTcVhEbjNxNDJVSnlxd09sVjVPVGZvNyt1Z0tDcFR2SzFsbWNC?= =?utf-8?B?VXQzeEVOZkhrQmVNUUwxLzM0SjcxMUJNWGVlOXIrS1dGNkYxWjVacGJZbStP?= =?utf-8?B?VlZzWkFWZ0NXbHFFcE9wOFhWd2FRNkNTdUpHSnZvdWovcGpRZXNraWFvZHU0?= =?utf-8?B?T0FNQzJWaU1mZVlibVNoNGFiTytlK1Y0TEhnaUFEa2ZSb2N4T3ZaQlVUSjJS?= =?utf-8?B?SzcvaTRlYUFMOGo4MDZoQXljQjFwdU94a25HOFZrT2NCZ1kySGpmNWlxbjJC?= =?utf-8?B?ZWdNUDFuU1F5KzlTWjZVOGR4TFFCcVhNUGQyTlBPa0lXdVpwcXk2MTNNZjhK?= =?utf-8?B?NGNoU21XRjEwOXBXK3ZFcDFyNFAvcm9QRDNnRm9LREtQT0hlYXAvcXRxcWpk?= =?utf-8?B?VGU3Yk9FZ1l1TlVuRVk2WUcxSGhnQ3RRYmc5dTNPVXQvOEh5UUlyNTI4Mk81?= =?utf-8?B?N3Y0dmZ1eVl1aW9rMVFwbU5rSkg1aU9kdUpZUHFESkFBTmlOU09mb0l2UUZG?= =?utf-8?Q?CiE1pnbJUHU6cEYUfKgkLWLAK?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6004371e-00bb-46c2-e7e8-08dbbf50b3e1 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2023 11:55:54.0953 (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: gxeZw/k2s2lYtqEvOHT9MT1gMC9FDyVLy97RDQ8OC79w2jOIiU1d22rWPvonDXHl X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7701 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/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. 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. 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. 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. 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 >