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 37EDF438F3; Thu, 18 Jan 2024 14:21:52 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F341340295; Thu, 18 Jan 2024 14:21:51 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by mails.dpdk.org (Postfix) with ESMTP id 7F65F40285 for ; Thu, 18 Jan 2024 14:21:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1705584110; x=1737120110; h=date:from:to:cc:subject:message-id:references: in-reply-to:mime-version; bh=T3+8i1oBogPJFxCpHpw2NWy1y6HhV59gfmOoW2biVnY=; b=nvP4+EWzfRkKWmUxI+i2hNt4GwuPEshyRmoxLCBnd/CBQxS8uxvVTMpa zcuhoYOfZw0Ox0NE0T0S8jeFbqghz5NOt9n7LIji4XeQutnYR/KtHx7RY eYSbUnLe7ZdGJ3dGs45nFnFf/3ywybJuD8wb66qTT+VyxLrEjVzBHJVQY 8Z9cthngOWc+lrKkGHLN4v4Qolw7loSBWyqGleNQcdW0Dl90RtfhMS7Gy Lvqftsx8psPPKhtqBAtFia5zGKrci/xXTs4ZYmTmYbE4xQdHDD6O8f96G WJGujPHWgk6DEWF8XADf3T18XKgqdU1OJs1gByVHBT0sRIGTd63dQfb0L Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10956"; a="19038537" X-IronPort-AV: E=Sophos;i="6.05,201,1701158400"; d="scan'208";a="19038537" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2024 05:21:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10956"; a="903830808" X-IronPort-AV: E=Sophos;i="6.05,201,1701158400"; d="scan'208";a="903830808" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga002.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 18 Jan 2024 05:21:48 -0800 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 18 Jan 2024 05:21:47 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Thu, 18 Jan 2024 05:21:47 -0800 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.168) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 18 Jan 2024 05:21:47 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UcXI/nyfTNtJOUPDG/CxLTCPncdujlTgHb1flRYvfOYS2uIUXvrec2z+0kE1bu5MOevGQGlY/UbXM16FnOfMCHak8LeuecUfd//ffnA3It5GFtZs8GmFqshyzABzSDecCWK5imRhg7/R0DfFldCu+UJASwLbHsbvLn5ipegjoInqgfHpP+4B5suPkoIZeiiSgbTJ0UPA/biR7qu5PyQa4i+Msu7PyPCrKdq01pQ2gBabNtl37vzGFR/UWvTQw+uDGywxyRXGnLNneLfNKlSiCm5nsAqEE5xFNezZ40a0rJz20hylcw3NCePIPKeauIAc8kPw52O4m+KvU/pO0Xu8dw== 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=sv51Hi37bQ0f/RMJzRh1xdERPc8WUIIRfNvmST7FgAo=; b=lbPKZlb8ymOt7ksYToOwY/G3Fy8MEX9aE7QmaLlkx+NhOMRJMrpmcxgZd42wF16gwogAkDUgOUAjo4S5pAs9OSjaI7CmNfxBMb4Cro82uTPw4c4r6ipokqH2V28ZOzZXRQ68T2tx376l8qPoMBLMKfQU9R08tw3rCyjNKhLiPRQLYWuh8evkxVt6cAg95o5zy/Sl2jceLk3PgDwBC27qTxkaavLYZkP+2TpXF19cXj//gDXJAF50sQOJrxqu8zf63irbFRpAunOZMMH0dfEjQ7FFf7JwCWyANCgg0NhfIvpgp7NDIWUjgDAmU9TZUsfFBnM4420izFAsJYEbAdx/DQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by MN0PR11MB6302.namprd11.prod.outlook.com (2603:10b6:208:3c2::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7202.24; Thu, 18 Jan 2024 13:21:39 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::df88:b743:97f8:516c]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::df88:b743:97f8:516c%5]) with mapi id 15.20.7181.029; Thu, 18 Jan 2024 13:21:39 +0000 Date: Thu, 18 Jan 2024 13:21:34 +0000 From: Bruce Richardson To: CC: Subject: Re: [Bug 1368] inconsistency in eventdev dev_info and config structs makes some valid configs impossible Message-ID: References: Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: DU2P251CA0018.EURP251.PROD.OUTLOOK.COM (2603:10a6:10:230::21) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|MN0PR11MB6302:EE_ X-MS-Office365-Filtering-Correlation-Id: bbed1008-8262-4061-8ebb-08dc18286783 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4C1z/TeBA/Wv3eGXXgDHbmyO7q/Es6HkUT9DhMoVkGXwloCFgIzNxrtb+414zAmBp+MB7eqpCSTg7TUYU4nWPgeFB4Pet+7Dn9Q6D8ICe6yW2zOjmNq9ZEQOHNz2bqe/EVTG2U7ZNUKzIPz5v7aAlW+AiZBAwx9/9qFT4SqFNyvtIErCdjLuQDogHSkk3DrzOpBG+NGjw6VtrQajat50ZGiN+LqL316jg4JVhcb5eXNa9oJysSVuJV5EFYdSh08mIE/PBK6JV79Ijydx72KEmYW/6lDBi+pvWXJcwOGyvTbwVdjWbALu40NISfmVboCjDFqJanuQmBTkGmPPkLRNHGNuhiK2SJ3p8ZdzyouvAoRZ1pi7kIbDF4rZdP0M6jo/+wNEmoncky6Iszw5sGrnc7KVC8+xZew6yN/l2msfjBMCRDvuWoeksPTqFb5SaKMXaH2whNVOOeG+vyKbjisREVOjOYGBOqiz7Qe3V76+p2b/yvsS1v/riEWs0nm/l+74NDI7hyl6y+4RJVBHoxbIGAPrnaJZNTV6G/YsztBRyh7h7acvXhV8Z5EJI3tZz/rT X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(136003)(366004)(346002)(396003)(376002)(230922051799003)(64100799003)(1800799012)(186009)(451199024)(4326008)(83380400001)(41300700001)(86362001)(82960400001)(38100700002)(478600001)(6486002)(8936002)(44832011)(66556008)(66946007)(66476007)(8676002)(316002)(6916009)(26005)(2906002)(6666004)(6512007)(6506007)(5660300002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?F7WD/0x/5gA9MQcppW2zNX7WzzNvGp4n5srnzKRlE1NykX9S3lZzoAMkO1du?= =?us-ascii?Q?VEP1Ie2N5xG6hSiEhysqgD7tvb3i+fmYxKQMdGWfhioNzhiqqJwcfPZJktQO?= =?us-ascii?Q?H8mbFXXHbhwpmkkR9q0GLYLhJRODI+nessMrBMdeeEFUH/P/B6dfPtRyCLFS?= =?us-ascii?Q?ZY3ZzDqdIVCayeRrw0DE0H+BJJB+6vLNhH+qbK7S9kQylUPBbTaP9xly7UXg?= =?us-ascii?Q?Cyv9cuUJR2mG9b1KuwCtDLQbCBGv8p5YpDYIdrtP7uekk+zM3kO6AwQ2k4k8?= =?us-ascii?Q?AmmGg4qaOBXMo9Fm3it4k97HBXnDMdKaIMGPdUzCznyfidUYCTuf8dCbh9YI?= =?us-ascii?Q?kr0Eph8OCbMPQUz37UfSmvRQbQj8+N3PY/EDYeqoxlvAKLcs7MFqbDdQo73B?= =?us-ascii?Q?9W6VyjKNzJGGV2V8YXeOkYvSFb+KwP+WhkzDzul9PpBcVvoBV6fDyEexGr2t?= =?us-ascii?Q?vJvoTID0Rfc6LaYD80FRkOzz3xva2joCx28Y39wY6XocHt2e0rIb1Hc+N3Vj?= =?us-ascii?Q?Nafiydy6LogYOwUvA55dGcFewdIgiUqTXwKZ+/bjgvoEGm8ksRCWsvxlkLaf?= =?us-ascii?Q?dTIDyL/2s6KdCSIbMkTOMpdF0zoYkCA6etAr+gs8jZXYhP3SMfzQMqH411I4?= =?us-ascii?Q?Vm1FDfCroV2MSe/2VCRvSqjYCTteysPt3ZXlG5xhZ3O0Bgtr9zzLtiuELKVB?= =?us-ascii?Q?ubBn4lcpke6CyMujgUBzV2caP0JerN2gvsNPVe74qe5evG5NRWSyHdPXVoqg?= =?us-ascii?Q?Md/lCx6m67S/4Neq9PNzJ3DK0eCFhcCUnd+yO1P2Ls7AzwVzs3XRQh4TgqY5?= =?us-ascii?Q?3z/9Xp4cWbjaggfe9lmdq5mLP1BkCQnsrEnq6PbkyJnKZBswQI8dGdsnYC2j?= =?us-ascii?Q?jRWe3GT6QLUs98Qkialf3CiL1EcSK4b/QJypuHXDFiSvAjClZfAOD7YbW7f7?= =?us-ascii?Q?rZjBwNUzrEy2Hx29W4CtmMftjJzSUpao5oyD2HGqker7NaemHMJmnWTb37a9?= =?us-ascii?Q?QKR+N/gEhnggHwBz8K0NzmmRaLIICEsjQUdX+xAtZgCAPkxvtmEl5BKABZrk?= =?us-ascii?Q?PFJFwlV++JoxBUQTHv3zDA43N3Vqe/e9+wQvAwSlA+gM+RKwufnKUxVCEaDu?= =?us-ascii?Q?zg1+49nhnxG5z/r6dDwqUubYjqOnxyEsk1aV3XAHQhdKt/ZmFTOEunUqePT+?= =?us-ascii?Q?3tUF1yaQ0NHngiWhRHA7DkWs58jxAd6SPKWW2glnm8YfeMAP8Zc+9JlPt0Ti?= =?us-ascii?Q?+h/9KIeSbFsbaDCExLOQG6dM1Foqsmr+38ax7U54WjiZaMr6x0Nl28I99o+7?= =?us-ascii?Q?iTwjFRogabFtjjA+RvE9Md8ofsxyu848xE0CELaL7U8Vjg7lfH0b+wCfz4Nm?= =?us-ascii?Q?O10ZPRrLypENRU1XT7zFSHlizCn+X8SKe0Lzi9cDn0R1K4iYDKex1dewNp+P?= =?us-ascii?Q?zpvcdiKxbniwcu+RgjPEuFKXG+hcxIiKHPI/cPgxyY7KtHjay4xJdHC1NGmQ?= =?us-ascii?Q?Grc5pLypqsEnf33iEuWdx26AP/JQJN16rkb8PdMwNiD23fifhVZ4uBaLKSZz?= =?us-ascii?Q?ZRX8gPHokffJyuXfy1cdw0v2SmyCGyx6BGTXysWLkn8OCGMRt0uyMJfa6pwM?= =?us-ascii?Q?IQ=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: bbed1008-8262-4061-8ebb-08dc18286783 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2024 13:21:39.6343 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 3MootcZu3h27709QONUlm4XmR8gH64AWX/CiYUbrCNPNueOYRWkZIsRh7tc8MrQrTSjsUr4ggLBLrpPluVinRzG/CNnSK0Wfm+xTlfGu5+s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6302 X-OriginatorOrg: intel.com 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 Thu, Jan 18, 2024 at 11:26:45AM +0000, Bruce Richardson wrote: > On Thu, Jan 18, 2024 at 11:18:58AM +0000, bugzilla@dpdk.org wrote: > > Bug ID [1]1368 > > Summary inconsistency in eventdev dev_info and config structs makes > > some valid configs impossible > > Product DPDK > > Version unspecified > > Hardware All > > OS All > > Status UNCONFIRMED > > Severity normal > > Priority Normal > > Component eventdev > > Assignee dev@dpdk.org > > Reporter bruce.richardson@intel.com > > Target Milestone --- > > > > In the rte_event_dev_info struct[1], we have the max_event_queues[2] and > > max_single_link_event_port_queue_pairs[3] members. The doxygen docs on the > > latter states: "These ports and queues are not accounted for in > > max_event_ports or max_event_queues." > > > > This implies that a device which has 8 regular queues and an extra 8 > > single-link only queues, would report max_event_queues == 8, and > > max_single_link_event_port_queue_pairs == 8 on return from > > rte_event_dev_info_get() function. > > > > Those values returned from info_get are generally to be used to guide the > > configuration using rte_event_dev_configure() API, which takes the > > rte_event_dev_config[4] struct. This has two similar fields, in > > nb_event_queues[5] and nb_single_link_event_port_queues[6]. However, a > > problem arises in that the documentation states that nb_event_queues cannot > > be greater than the previously reported max_event_queues (which by itself > > makes sense), but the documentation also states that > > nb_single_link_event_port_queues is a subset of the overall event ports and > > queues, and cannot be greater than the nb_event_queues given in the same > > config structure. > > > > To illustrate the issue by continuing to use the same example as above, > > suppose an app wants to take that device with 8 regular queues and 8 single > > link ones, and have an app with 2 shared processing queues, e.g. for > > load-balancing packets/events among 8 cores, but also wants to use the 8 > > single link queues to allow sending packets/events directly to each core > > without load balancing. In this 2 + 8 scenario, there is no valid > > dev_config struct settings that will work: > > * making the 8 a subset of the nb_event_queues, means that nb_event_queues > > is 10, which is greater than max_event_queues and so invalid. > > * keeping them separate, so that nb_event_queues == 2 and > > nb_single_link_port_queues == 8 violates the constraint that the > > single_link value cannot exceed the former nb_event_queues value. > > > > We therefore need to adjust the constraints to make things work. Now we can > > do so, while keeping the single_link value *not included* in the > > total-count in dev_info, but have it *included* in the config struct, but > > such a setup is very confusing for the user. Therefore, I think instead we > > need to correct this by aligning the two structures - either the > > single_link queues are included in the queue/port counts in both structs, > > or they aren't included. > > > > Since I'm doing some clean-up work on rte_eventdev.h doxygen comments, I'm > happy enough to push a patch to help fix this, if we can agree on the > solution. > > Of the two possibilities (make both have single-link included in count, or > make both have single-link not-included), I would suggest we go for having > them included, on the basis that that would involve an internal DPDK change > to increase the reported counts in dev_info from any drivers supporting > single link queues, but should *not* involve any changes to end > applications, which would already be specifying the values based on > nb_single_link being a subset of nb_event_queues. On the other hand, > changing semantics of the config struct fields would likely mean changes to > end-apps and so be an ABI/API break. > Checking the implementation in the eventdev.c file, I find that (unsurprisingly) the implementation doesn't correspond to the documentation. For the problematic configuration described above, it is actually possible to implement, since the API checks that nb_event_queues (and nb_event_ports) is < max_event_queues + max_single_link_queues. I will patch the documentation in the header to reflect this, but I still think we should look to change this in future as it's rather inconsistent. Regards, /Bruce