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 0032A438F2; Thu, 18 Jan 2024 12:26:57 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7797740DF5; Thu, 18 Jan 2024 12:26:57 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by mails.dpdk.org (Postfix) with ESMTP id ECE04402B5 for ; Thu, 18 Jan 2024 12:26:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1705577215; x=1737113215; h=date:from:to:cc:subject:message-id:references: in-reply-to:mime-version; bh=hsMnOPkoHZrZ8sNvqL71U3QxewhKU/bjNDKBkUgfc88=; b=lpiWWuHCE4nV78mMmtLhVnnq6Z2oKLcL2NT+VCY4zEiCbeUkV7n4NXrb eKtrXp/MsU51tLGuPmYgjyLLiMmxER4vdVr7PL+DRbMZqtXO+ufVFcGpz QEylaG7wvs4cx0CERxhCS7c7HLYAW1lUGq4jnMUiybZUUFqEwdCgNXi2+ NSjegzMYX/+rRKDi1eCPimo3eOsxKDiniiwSQ/w6MFR+jHxRPdd70FDWF LIoQEUPw6t8Br54HRrALPBzJjPF7yCdRMYzizzOY1Vucee6uUhAqcX8DV /3yBV9mCw4koMZtVisbemIg4o1WjufzCZBeaaxf737dgpl9Xs38JpfzBB w==; X-IronPort-AV: E=McAfee;i="6600,9927,10956"; a="21902629" X-IronPort-AV: E=Sophos;i="6.05,201,1701158400"; d="scan'208";a="21902629" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2024 03:26:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10956"; a="1115935384" X-IronPort-AV: E=Sophos;i="6.05,201,1701158400"; d="scan'208";a="1115935384" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga005.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 18 Jan 2024 03:26:53 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) 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; Thu, 18 Jan 2024 03:26:53 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx610.amr.corp.intel.com (10.18.126.90) 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 03:26:53 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.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 03:26:53 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eqH2Z61MyrbmJ/jdq2W9Yoi838F5zaQ3r7T9smEwEL6X9XVSByEhujF9aVBbPK6p0CKzwEWKLwJsQR/6fZvV1c/tRr5WB5A/aaqsYxNxejoEvoXrQG3+uBZZ70t01tMeIpMtwcbeHD5mWjthiKX4+110dwVhditBYsS1RbWbHiE2x8KqVPQTA7ApyxEO3kZ+SZmL5Gt+ybMFIkQ5TJSZnnf+lCEq0Qlquh4a7KsQ4TN9ulz3TseOgaKZsE50nxw7KTp/cAPN2lORvwLTJsda0RK/fw4ivoDTimx/zn7ipM+zDLokeWTV184pR94H845ToKDUEZLIBTJdwAEjwOkc/Q== 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=PEMDspBD+V8gGqBiAATm35nC8XOVFoDaGHjGQ+ReFQs=; b=CTQnZHq8lQ8Pq/6fOWIGXEEILac4IKf5YMEAxqyheDE/uiUkgxylODe/4fplPrkz2BlM3I6ZRdRzTqGbangbClLtpfpQha5RzKuYO1zUDcS4iMdG/JHFevZnnlqhTmt/49i47WBIVq41Hm6zzcWLH3rjmNRD+4LR0bKS4V8+2V4jzKW9hWNy9zHbrtCw81Kq2QnOLXhO00Y532lQQ+mMJhrm5fRBYw3scUjcGe8rb3wUiqbwbM5gIeAiBc/ScNhilPXWhVy+RKnVpqnEcERSXoY+klOqQrW87cqXiMneetj5UflDxsxozHY6Gee020C061alWzcSwhx/3tB2IYSH0g== 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 CH3PR11MB7916.namprd11.prod.outlook.com (2603:10b6:610:131::15) 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 11:26:51 +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 11:26:51 +0000 Date: Thu, 18 Jan 2024 11:26:45 +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: DB8PR09CA0004.eurprd09.prod.outlook.com (2603:10a6:10:a0::17) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|CH3PR11MB7916:EE_ X-MS-Office365-Filtering-Correlation-Id: 1e369fa6-d0d9-4c5f-feae-08dc18185dac X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BUr9zlPNAUF6ZfOtzvGt3v57FBQS8TJJrcFIaza9a7Ba44OSGE57xKu6aydRLgKUUxVARB5j8FpmbMqVG7doXXt3ZaigqIY1K7Beon5pvRXi4bWb9fhHMpmbP5PnbQTi6FFvm8Ta8/nY1PSe3BAez5YtNW3wUv1FW4MO7RG2evGNL+grgbxBqaZwrok0duxdMTI0zeCf4KCSmSY6DpE5ik/Drp4jHwQQ8EBh7tCfM/cHm2X9LHqlj0erVkvHebxHHOnXDEmdNJw7drc4BiHj1GX23RIBDsIoacTCksmYXVkVBch+tDZPJj89C/8IdZD/Z/4fnIfp2rCNk9q/4ZN7CllWP9o6wU8u2gc8lCZb4ZaKTCWeMj1QGZfB9ox7j3YqqndDuBWWlGsofazcAQipC798BoTKaO4ltHnPb8EMseFXz66jvWQwrvLK1WaBzYytoYBQ4tMQ3VwfJvpsZI/ye6L6BDmMfT7MCKoBeoyXx4xwxeMtc5BQlMFaPzIH+5Pk0LJQzY33InM92BxZec2p8JTUDTp4mEsXn+Sn8lzSGLGprbZ4IuNRn+LAUZMZgiPY 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)(346002)(396003)(39860400002)(136003)(366004)(376002)(230922051799003)(451199024)(64100799003)(186009)(1800799012)(4326008)(8676002)(8936002)(26005)(316002)(6916009)(66946007)(66476007)(66556008)(478600001)(41300700001)(44832011)(6486002)(86362001)(38100700002)(6512007)(6666004)(6506007)(83380400001)(5660300002)(2906002)(82960400001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?puBVlRJIFmbFBRN15lYbPL8EqNsR2S5/Pr6TjchViwYDoeBbnJ+WEhRlQG20?= =?us-ascii?Q?MHtuS8atL2MnZi6XUri6XD2fKZopkVWNkxSCayvHcWy2djfSsnBKitRvfzJo?= =?us-ascii?Q?zcxCsmXhObp1ittd2ubBuUqqW3Pq/szXsvXOSu4342VL20M+Z7yD/2xVva/3?= =?us-ascii?Q?cKiF1GyTLojKkcxr105mhGHjqEbq2TPLCGBJ7iaxa88Ivynnlyu4upjqlm7u?= =?us-ascii?Q?nTCNelOUGTRheGI4i+CS/3CTrfhVQwYwrtonb4HwhOo857D2TB83CZKSpCgd?= =?us-ascii?Q?tf8QubuXS53NBf8N+ETG+GoC2tglgwKYeHomRWJll5zZ8gpFPjHYOELUyJh8?= =?us-ascii?Q?Q8PBzfrIUzCaQC1791yHcN2Ib4K6sTEN736F2rwEVCnHC7lZyEv6Tt+mE1aT?= =?us-ascii?Q?iw1X4a3FOrDTVQ2szB9/Aq5jD8IbXZPxbuloOlSdgOkkMVSgnSCEtAQ//fWp?= =?us-ascii?Q?7NERXg4ROYislhAfsRWGyarZcB7kZnV0sirdC7XmIylM2dwTSXZ3A/Z5lpnj?= =?us-ascii?Q?0KTpu65fIjuFvttlYRDx8tonM/B9LLXaWDCtFLTvnRzMH0M/NMlY1aXVVKa+?= =?us-ascii?Q?lVACVkeOp/eDb0rqvvs56GzpRlrgsna1NmG63X8cMBRuTiLQvngRETbcmxM8?= =?us-ascii?Q?Z44ZMsCn2CI3Rs1Nr+2O4D8VAFr71wm1g+ybCBsMVDt2KobKL2gJaOXb60c6?= =?us-ascii?Q?on6owX7HA7YyVdYqFllb4r2aXdtiaWbPDEA3tnEtJWpEHAnY8QxIl0bfrvbl?= =?us-ascii?Q?0w9jOXLOJQgSo+gLwWD/RpHlipMkYhHeoSk1KyrprXSauIBzwphOL25UaXIM?= =?us-ascii?Q?mmf1iZgqXk9eziODfZ36WwX1p5Dquh7VQkw8ocDvdAQRRPLa/wFi4QYIZWEq?= =?us-ascii?Q?r2tJwPc3qp9xlz4P/qfy54BvlNl01RJGR461buFyhnDj6MknMGnq8U7zrR/3?= =?us-ascii?Q?Fl+nSl0pSPeToz+9NdZwYd5dCWIpauVWBf7it4UUHn1FSBG7aNtGB3U+Ykq0?= =?us-ascii?Q?NghNHELYeUyeaa4RBK/nWn6EDYXhRlL9krf+a0p1Z3GVHIehVkOGWGUcP+n8?= =?us-ascii?Q?qcmvcUJOcb0pRuyzUhBuCnPlILCYeUykEWutRHad8qDfaeZH6LFEJOAUOqvh?= =?us-ascii?Q?GhNlueegQrBdVmsY2Cos/+I5ShytBIWtiml8tnqhIviK2o7xkex8wLKaDmFv?= =?us-ascii?Q?K+7HYmmqs/+er5ZDglkCULjiBCY6O5I16mfpBTEv3VnSn1ftk4xbCx9tNh/D?= =?us-ascii?Q?Mh1IdkLQ73iR4f/vUukfAVuZuVueXc1oSYkg4oMsjE97mHCpNnf0jgQujX4T?= =?us-ascii?Q?7HNFOEENOrtft+qe9jZTQiMs9Tht3VrR+rkmcu1FGU66aSFrnHoHFKb9BGzn?= =?us-ascii?Q?y9V5FPD8G204Aa66KR5cXxzc0y/9bvw7XoLg5C/mbWpY5eVnk6YC9QOSsLX0?= =?us-ascii?Q?xOVEnOZFjqYN9TS8Zj7zoyyvrqmjYamhXAnRItARBfH2c8rl2JNsZalNcD5b?= =?us-ascii?Q?N2+3Jt9gATg3wTax2ZaHB/LVcXSTGF5SSKtD9PJfKRSPy7VoAf0n7whIA0L1?= =?us-ascii?Q?hRfMENl5O7l3jRMeh+tZk8eVHJMOguOJ56X4Wurje8THXGMDGEssyENoml2h?= =?us-ascii?Q?Yw=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1e369fa6-d0d9-4c5f-feae-08dc18185dac X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2024 11:26:51.1602 (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: uA7BXaYZfze5HVb3lmWrp31XuRjWWgEOu4zPSswUelbRsZXYEqH7yKqD5IXKjf9y237Y6l7Pgi+ggrtIkosTxkep6eKOxuiecO/r33bqz1s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB7916 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: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. /Bruce