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 04C2845A3C; Fri, 27 Sep 2024 05:31:07 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A4106400EF; Fri, 27 Sep 2024 05:31:07 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by mails.dpdk.org (Postfix) with ESMTP id DF8894003C for ; Fri, 27 Sep 2024 05:31:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727407866; x=1758943866; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3ITGf+fTkHTnK8V6zTztinQT4hXWFQvPQeTdbvfn9kU=; b=JlxQyZPLkvOGsyu6KBXtx/n4aWRrcM4seswJ5q9BcqVkwyD6/JvL1inS qt0rBQsi9dcL6+KZSaxccT2AnOGEtCago5Y7RV35Gg4YUjyy4undurBit vjb9q9DeauD/wjhBb5aPG9fJYnyqGZYHZ5elWB/HEJbp0Es1IG3l3v3WO ljQSJ6x0EhH/BkmY9HwI18siO1mNtS5Vgd8SpjZycOFseZ8O/nNspG6BF CxxmJJrVUd/nhZLcJhEVG4nqArzyhcVfUsGc+vYnAEEv/3Kg5yXi1wiDc N57auk3meiDtnDnHg6aUaIY2cgdbUOQp0sdSZ+DRqLUVINLq26eUHE9GN A==; X-CSE-ConnectionGUID: v0UJxhpvTaa4RlkSQK4eXg== X-CSE-MsgGUID: lV7jdRA7SX2rdMqWQvK9Ng== X-IronPort-AV: E=McAfee;i="6700,10204,11207"; a="29423557" X-IronPort-AV: E=Sophos;i="6.11,157,1725346800"; d="scan'208";a="29423557" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2024 20:31:04 -0700 X-CSE-ConnectionGUID: 3MaQFWJzQz+2H1U7r1QQZQ== X-CSE-MsgGUID: gefxjM7BSoOreyvYoRE0Iw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,157,1725346800"; d="scan'208";a="109866730" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orviesa001.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 26 Sep 2024 20:31:05 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 26 Sep 2024 20:31:04 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Thu, 26 Sep 2024 20:31:04 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.172) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 26 Sep 2024 20:31:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eA304X0KogvjvUcKroBnnenK8Ia8GZ/BW+8o+jLWx0QIWYtgZAe7ESFK/pFnFMAdGfYFUCtAL/msoXBbMKa9F7qlKwX/JLbjnYdGIcjMTG073/C4V5qRoOUZyF9anSgvp5iM9HKgxM4wvc/o+JEYVEUiwmab94lSYDDp3IPADz6SaikXq+lJ8xc0g8RCax1uhgCnzS98IQOEuCSy5Ad+1qXcpiWBupEWx8SmSjuLzwwWXC4XTlP9tLF8a60lNvzWDJ8ilIqE4AISwKmuUnNeOYm0T4FLXxps6LFNhmKxXos+uAxrWnztDMWQpjyA/4lEnKPUnQ/G54RTKTh/hdyjMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=3rzOF7jHIddA4h2bDCWj6jL25bdeO+cUY1SgCbv0rRc=; b=VtZ4B12HlzizHcbOqY27A+z8yDL3ey3c0vtObZkskt8Rmq9qNp9U6rm+EZdis9eFLwqGHvkY+k5K6SK7t5oQG2PqoQ4jg0jw/DndB7OrA6KYGxlfN5zBGFYEQ8CB4ZG85eRZx56Lpp0b/W7bZ4BPJBRsivDQhgB56xV65MxcsQSb3ttcj/QdxxjSB6yWqtXcGLrI9oN96cS++QXyvGjJMhiLgWtT2aYw0GrB7NqLD/L0JGjZA4T0xNI/OZOX/O1lh5nJ5tgkFcUm7CR9bS0fBGqb8QRv6u3qriBpR2ryeGIqtwDcB1unth9IoaZs5WRZJwXh+eK80/qp9FOhrE78tw== 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 Received: from BL1PR11MB5461.namprd11.prod.outlook.com (2603:10b6:208:30b::17) by PH7PR11MB6697.namprd11.prod.outlook.com (2603:10b6:510:1ab::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8005.22; Fri, 27 Sep 2024 03:31:01 +0000 Received: from BL1PR11MB5461.namprd11.prod.outlook.com ([fe80::8d83:7a30:43c4:835a]) by BL1PR11MB5461.namprd11.prod.outlook.com ([fe80::8d83:7a30:43c4:835a%5]) with mapi id 15.20.8005.020; Fri, 27 Sep 2024 03:31:00 +0000 From: "Pathak, Pravin" To: Pavan Nikhilesh Bhagavatula , =?iso-8859-1?Q?Mattias_R=F6nnblom?= , Jerin Jacob , Shijith Thotton , "Sevincer, Abdullah" , "hemant.agrawal@nxp.com" , "sachin.saxena@oss.nxp.com" , "Van Haaren, Harry" , "mattias.ronnblom@ericsson.com" , "liangma@liangbit.com" , "Mccarthy, Peter" CC: "dev@dpdk.org" Subject: RE: [EXTERNAL] Re: [PATCH v2 1/3] eventdev: introduce event pre-scheduling Thread-Topic: [EXTERNAL] Re: [PATCH v2 1/3] eventdev: introduce event pre-scheduling Thread-Index: AQHbCNDcT5AdjdUdJEysyuTDvRXJHLJeJMIwgAD1BYCABgGygIADPsWAgAERW8CAAHlugIABI1ew Date: Fri, 27 Sep 2024 03:31:00 +0000 Message-ID: References: <20240910083117.4281-1-pbhagavatula@marvell.com> <20240917071106.8815-1-pbhagavatula@marvell.com> <20240917071106.8815-2-pbhagavatula@marvell.com> <95d75412-3600-4e70-9a06-438af8cc09ea@lysator.liu.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BL1PR11MB5461:EE_|PH7PR11MB6697:EE_ x-ms-office365-filtering-correlation-id: beff4c51-9377-40b9-428d-08dcdea4cf00 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|376014|1800799024|366016|38070700018|921020; x-microsoft-antispam-message-info: =?iso-8859-1?Q?/ZBnsX+2wZG+3mO7z+Job+i82Jt8nZRLAnMPgDHN0+PgQLyHGVtwcSoLB5?= =?iso-8859-1?Q?paHYl3YPhcEMhOOTF3zf9ICjadWre0ip5nmzrL4HUJrl0Ma9mn7PpGFeZD?= =?iso-8859-1?Q?v9x/qsY4AyDpVsVe5o1ZCQjIymMRvBE7WSVkAMvR641+miNJ7b+jJtT8rh?= =?iso-8859-1?Q?yGcCoCSsfYxqI1+ZUEgyFWpNjzi+e2jFXuMRuDrF5ANMMLBZqgsx7X0HfG?= =?iso-8859-1?Q?YUaMWVjlL5PS0M4YcZXjHAn5u8pQPi0eFJd9JEw8JK//z+2/nrXRIZGOR1?= =?iso-8859-1?Q?1uqVH8cC164/rH2f8Hs/IbiNWNw6Izcl0MeSHmgPzHMrKNds0IqNd0aRWv?= =?iso-8859-1?Q?BsSsphlF4AobgXPycv+aZVDNQmYeBuCibp+rOChsETxM3CQ0u70u+LxA3e?= =?iso-8859-1?Q?d7IA8dpxuHjH1fk+ZqXxL0fcNUwoVWhXVN7qm1YKWb5JtFYRNmAt0G/ldE?= =?iso-8859-1?Q?MYmdUlWawQAE77UQVC7nrfK24/6SQhe12563DmijnNvNPW/E8CwSaBIrL9?= =?iso-8859-1?Q?WuCPDymgbzfC8P9FFMKXa6DJYJBHWAQVD90dgSeh6I+ClLrRBkmCScMN6n?= =?iso-8859-1?Q?ysrbFd75G3FLt4dw9+D/sO2KF5VvQPTfOfj0E/iCAkLLVljPD5uW97ubt5?= =?iso-8859-1?Q?cE3+PSvol1qmKh+iQp3mAxWQzSeY2fAagnNLV5xc+kZePNx1GuwrBu6bP8?= =?iso-8859-1?Q?xrBwGwa2Wb32Fkh2p/Ol22JSriLERaMaAZzu875yJjg9CUFEHYJo9kk0R8?= =?iso-8859-1?Q?7vEHiFhrcL6VZVgQ+a2QvL2cgcOHruXKwmgTEoI+xwaGXvm0fzTFE3UVP/?= =?iso-8859-1?Q?HIEOTtLw5vM6eUAFFZOwzzVBGcicDIIvVxJPBFQZN4fS2IfC/79+Jvfor+?= =?iso-8859-1?Q?fZaTbDttr5cxIvlkTltRvAsKJWYWoR0pdyy3xK4SPC7T88Ujd6W1C4gw8N?= =?iso-8859-1?Q?ZIfzWKIRYPEu5NXe+2Bs4En/DT3t+mu6C48Hl4Q0Uf2Q+ULeAnZUHYImma?= =?iso-8859-1?Q?66LRdWWd1PE1uf7HlCwV8MWVg0hQBzcqzOzXR25Ktk2lqANAMtFwJO8CDS?= =?iso-8859-1?Q?EGf+kzNIZXcKgfvyP3t6k9ht1gWhNtB2iGV3QY1nr2guXlVlvo3A/wIt9y?= =?iso-8859-1?Q?UF73as/VqmRJ6twNx7Tlpkp+SBoulwe0sis9gXrELgKglUfwpxIyKM+2p7?= =?iso-8859-1?Q?Yv6cJ4Ukx3/jZPjobbYiqtU2JIkpBDyiS3zWM76pOGXQ2V7zwRb0zDKHC2?= =?iso-8859-1?Q?GMIkoVFvKDuInRGx5ivHtxdECrKHucltq0tIvCndBGJBr4S9fyBjfBXBJH?= =?iso-8859-1?Q?4lv/xvsdfrq88GVsHNuXrc5tOj622evB/DAyZfv7Ht4xBJyed7wsafwb3S?= =?iso-8859-1?Q?8kzByubPiH1G3XptltwH4ooh+3tOOUmohRsJ02g8Ro3YTC3U34zSvtv/NB?= =?iso-8859-1?Q?wGCZ92t79Sn6R2m+Lwqe1hAajsRcM/Pw3hGvPlG0H8GT7UTLf4vY85TcbO?= =?iso-8859-1?Q?4=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL1PR11MB5461.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(366016)(38070700018)(921020); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ICEcfWurtkLYjPIKZCmKiyZHRf/Dz1rvPKEdNxEPFufcMl6qCnLjlXMfc7?= =?iso-8859-1?Q?M7Q+q55XSwB6lwhIN93zuXDxjgzpuNDldR2gp99mmggmivqQKgAWdk2qbl?= =?iso-8859-1?Q?ByDGxdWi4+xb1btSqY6gP/hheCcKOiCAODM46ilChSYjO2SEjONB8J4+F6?= =?iso-8859-1?Q?v8P3MWK2cdCTFQT6zfaOEtt5oDoARQxGzcieawKsC/klsc3qgfg5ZqybJ7?= =?iso-8859-1?Q?gGG4Iv04MT2zRcAAXULwOtwjA7MHre1I2uBFAiBPJUDaU1kHbkDhNHJ5r0?= =?iso-8859-1?Q?S8+tSMz4lwvgv/CTQBQMHcmgr3YHEsQxTGVrFSs9vyQLCSM5/zrB28ZHR+?= =?iso-8859-1?Q?1TwGQ4XE7XvlUo+dsQHUqVcG7++UF1zvoyyMKEqUgUpqqYvtGJS7rrIcRB?= =?iso-8859-1?Q?pQciVd//5vpHJheMl5A2XVozcqdujgrNajrf2BeyL9krZNAv4qCSZobS0Z?= =?iso-8859-1?Q?SOwkgWxmF8LO2DdXc7ls0qLjP5qzQxSJgytKApTmFHzb7VpVm8SL4VZtXk?= =?iso-8859-1?Q?xHVoDqk7MZQAat/bcu8wejjnBF3Jk43jRkFTByP1iHL17UDTGZdYoOKxVJ?= =?iso-8859-1?Q?vBIdhyLOVbUPxgzyy67vXAGhYJk6IwlJ9te5lLQDxHJUMHyopbiqBoC1VF?= =?iso-8859-1?Q?BoETxYTauJ3qCh+XjY3gRQsLBfy1cCt1SKW+MVNdJE8gosekZJ3/BLRP+Y?= =?iso-8859-1?Q?f/DEyRXnuzKI+r/uShXt79iUZBpMBInwGDmt9h5jg9hhpG7Z+FVMi5kxU+?= =?iso-8859-1?Q?btRbNNJXRjUIErCOqeOskXvkq5kuUOiBm43nfmYpdZw/DrbO8nvqDg6MjD?= =?iso-8859-1?Q?PkTS+c+HGfDvleOJtyD4Hz4I8MT5tdFZ3AErcXDKq+ONe//PwAskyGKJa/?= =?iso-8859-1?Q?rjHwhRznFS/0MxRVSFc8Oocp1OiQ6UpbVQ5Q8JKHqa2uqKQLlVzDHU9XPb?= =?iso-8859-1?Q?N5npwFHff7Gaa0uOkCrNqff/p6sa02J+XdIGyVjwmQ05bw0B+qX3gHGxwO?= =?iso-8859-1?Q?gi8NSKNAhNhXlBwLjRNtIEEPULRf5z7eZHizbCNaRspxfK6H241eksjTzB?= =?iso-8859-1?Q?dDPaFAooTqhomOO2mN9/QRcHZyM+JSvfhcBto/lwx+9YeLdBDXcw7EVHIl?= =?iso-8859-1?Q?xjRKGqHeoh5zaa0xakxjD4/5p9Y3/EyF+1IACKQcs0a6pS96qpB0kbgJu0?= =?iso-8859-1?Q?gxTbXNie1xaljIyZr+yxAGP/WGs1xhZxtheOKkqtaDWH1KnNbRnaIC19J+?= =?iso-8859-1?Q?PX64ZtOFM4UVG3uP1ADpBMPjdVk/bcIW2otHl4+2dt4NkaXAKiyc4UWAGT?= =?iso-8859-1?Q?SC+2F/NVhvIH+fCLA2wkiBY3U8QGvNlFCZpbczM+5rJFkwz//x9r8XOfEb?= =?iso-8859-1?Q?HfDNSZ/Qyw0nw8KD3rplBBwTACW6/pKX80VRqKwBP0mb9E8Pg8C8qa15nX?= =?iso-8859-1?Q?Ep4rR0CqftPkfWJBowwKqdopJHoN9jl40cLx/F9it3fQ7RkZtumNj/Or6/?= =?iso-8859-1?Q?ZEHjghfWO4U9NyOyRoerCl794LfzVSHafmDMKyDzLKtV6FLnjBcRz8+AUb?= =?iso-8859-1?Q?138zFydUVJWPgMEtW1XffZUt4Mw1F+C0gk4K91xo9+0nphb+Ps4zrnX9Uu?= =?iso-8859-1?Q?CzH77jjXrbB96ZsAxh5yILwjiYPZojTs0B?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL1PR11MB5461.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: beff4c51-9377-40b9-428d-08dcdea4cf00 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2024 03:31:00.8388 (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: 5Zpsn1sJtovhR08fDy6Kfrd0iOo4V3zvdxcMl26YKyjmm1sMhnc/AoS/5rKXTYbKOc3RoGOPvQaHrcd2KGQZFQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6697 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 > -----Original Message----- > From: Pavan Nikhilesh Bhagavatula > Sent: Thursday, September 26, 2024 6:03 AM > To: Pathak, Pravin ; Mattias R=F6nnblom > ; Jerin Jacob ; Shijith Thotto= n > ; Sevincer, Abdullah ; > hemant.agrawal@nxp.com; sachin.saxena@oss.nxp.com; Van Haaren, Harry > ; mattias.ronnblom@ericsson.com; > liangma@liangbit.com; Mccarthy, Peter > Cc: dev@dpdk.org > Subject: RE: [EXTERNAL] Re: [PATCH v2 1/3] eventdev: introduce event pre- > scheduling >=20 > > > -----Original Message----- > > > From: Pavan Nikhilesh Bhagavatula > > > Sent: Wednesday, September 25, 2024 6:30 AM > > > To: Mattias R=F6nnblom ; Pathak, Pravin > > > ; Jerin Jacob ; Shijith > > Thotton > > > ; Sevincer, Abdullah > > ; > > > hemant.agrawal@nxp.com; sachin.saxena@oss.nxp.com; Van Haaren, > Harry > > > ; mattias.ronnblom@ericsson.com; > > > liangma@liangbit.com; Mccarthy, Peter > > > Cc: dev@dpdk.org > > > Subject: RE: [EXTERNAL] Re: [PATCH v2 1/3] eventdev: introduce event > > > pre- scheduling > > > > > > > On 2024-09-19 15:13, Pavan Nikhilesh Bhagavatula wrote: > > > > >>> From: pbhagavatula@marvell.com > > > > >>> Sent: Tuesday, September 17, 2024 3:11 AM > > > > >>> To: jerinj@marvell.com; sthotton@marvell.com; Sevincer, > > > > >>> Abdullah ; > > > > >>> hemant.agrawal@nxp.com; sachin.saxena@oss.nxp.com; Van > Haaren, > > > > >>> Harry > > > > >> ; > > > > >>> mattias.ronnblom@ericsson.com; liangma@liangbit.com; Mccarthy, > > > > >>> Peter > > > > >>> Cc: dev@dpdk.org; Pavan Nikhilesh > > > > >>> Subject: [PATCH v2 1/3] eventdev: introduce event > > > > >>> pre-scheduling > > > > >>> > > > > >>> From: Pavan Nikhilesh > > > > >>> > > > > >>> Event pre-scheduling improves scheduling performance by > > > > >>> assigning > > > > events > > > > >> to > > > > >>> event ports in advance when dequeues are issued. > > > > >>> The dequeue operation initiates the pre-schedule operation, > > > > >>> which > > > > >> completes in > > > > >>> parallel without affecting the dequeued event flow contexts > > > > >>> and dequeue latency. > > > > >>> > > > > >> Is the prescheduling done to get the event more quickly in the > > > > >> next > > > > dequeue? > > > > >> The first dequeue executes pre-schedule to make events > > > > >> available for the > > > > next > > > > >> dequeue. > > > > >> Is this how it is supposed to work? > > > > >> > > > > > > > > > > Yes, that is correct. > > > > > > > > > > > > > "improves scheduling performance" may be a bit misleading, in that = case. > > > > I suggest "reduces scheduling overhead" instead. You can argue it > > > > likely reduces scheduling performance, in certain scenarios. > > > > "reduces scheduling overhead, at the cost of load balancing > performance." > > > > > > > > > > In case of OCTEON, we see double the scheduling performance with > > > prescheduling without effecting any priority/weight aspects. > > > > > > > It seems to me that this should be a simple hint-type API, where > > > > the hint is used by the event device to decide if pre-scheduling > > > > should be used or not (assuming pre-scheduling on/off is even an > > > > option). The hint would just be a way for the application to > > > > express whether or not it want the scheduler to prioritize load > > > > balancing agility and port-to-port wall-time latency, or > > > > scheduling overhead, which in turn could potentially be rephrased > > > > as the app being throughput or latency/RT- > > > oriented. > > > > > > > > > > The three prescheduling types are designed based on real world > > > use-cases > > that > > > some of our customers require in their applications. > > > Relying on application to provide hits might not be possible in all > > > the cases as > > it > > > is very timing sensitive. > > > > > > > > > > It could also be useful for the event device to know which > > > > priority levels are to be considered latency-sensitive, and which > > > > are throughput-oriented - maybe in the form of a threshold. > > > > > > > > >>> Event devices can indicate pre-scheduling capabilities using > > > > >>> `RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE` and > > > > >>> `RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE` via the > > event > > > > >> device > > > > >>> info function `info.event_dev_cap`. > > > > What is PRESCHEDULE_ADAPTIVE? Can you please add more description? >=20 > Unlike raw PRESCHEDULE where every dequeue triggers a pre-scheduling > request in parallel, PRESCHEDULE_ADAPTIVE will delay issuing pre-scheduli= ng > till event device knows that the currently scheduled context can make for= ward > progress. > For example, in OCTEON HW does it when it sees that scheduling context he= ld > by the port is top/head of the flow. So adaptive can be used by different HWs to handle preschedule dynamically = based on=20 Their implementation. The end aim is to balance fair load balancing and throughput. Is this understanding correct? I am thinking of using these= for DLB if possible.=20 >=20 > > This will be more useful as per port configuration instead of > > device-level configuration. >=20 > In the patch 2/3 I introduced port level API to control prefetches at an = event > port level. So is device level configuration a default value for all Eventdev ports and= it can be changed At runtime using port level APIs? This will be nice. >=20 > It is not a port configuration API because Applications might want to > enable/disable prefetching in fastpath. Example use cases we see is to di= sable > pre-scheduling when application wants to preempt an lcore and reenable it= at > a later point of time. >=20 >=20 > > The application can choose a type based on its requirement on the port > > it is serving. > > As Mattias suggested, if this is made HINT flag for port > > configuration, other PMDs can Ignore it based on either they may not > > need it depending on their architecture or not support it. > > >=20 > If PMDs support preschedules then it has to advertise via capabilities, s= ilently > ignoring feature configuration is bad. >=20 > We can make the fastpath APIs as hints. >=20 >=20 >=20 > > > > >>> > > > > >>> Applications can select the pre-schedule type and configure it > > > > >>> through `rte_event_dev_config.preschedule_type` during > > > > `rte_event_dev_configure`. > > > > >>> > > > > >>> The supported pre-schedule types are: > > > > >>> * `RTE_EVENT_DEV_PRESCHEDULE_NONE` - No pre-scheduling. > > > > >>> * `RTE_EVENT_DEV_PRESCHEDULE` - Always issue a pre-schedule > > > > >>> on > > > > >> dequeue. > > > > >>> * `RTE_EVENT_DEV_PRESCHEDULE_ADAPTIVE` - Delay issuing pre- > > > > schedule > > > > >>> until > > > > >>> there are no forward progress constraints with the held > > > > >>> flow > > contexts. > > > > >>> > > > > >>> Signed-off-by: Pavan Nikhilesh > > > > >>> --- > > > > >>> app/test/test_eventdev.c | 63 ++++++++++++= +++++++++ > > > > >>> doc/guides/prog_guide/eventdev/eventdev.rst | 22 +++++++ > > > > >>> lib/eventdev/rte_eventdev.h | 48 ++++++++++++= ++++ > > > > >>> 3 files changed, 133 insertions(+) > > > > >>> > > > > >>> diff --git a/app/test/test_eventdev.c > > > > >>> b/app/test/test_eventdev.c index e4e234dc98..cf496ee88d 100644 > > > > >>> --- a/app/test/test_eventdev.c > > > > >>> +++ b/app/test/test_eventdev.c > > > > >>> @@ -1250,6 +1250,67 @@ test_eventdev_profile_switch(void) > > > > >>> return TEST_SUCCESS; > > > > >>> } > > > > >>> > > > > >>> +static int > > > > >>> +preschedule_test(rte_event_dev_preschedule_type_t > > > > >>> +preschedule_type, const char *preschedule_name) { > > > > >>> +#define NB_EVENTS 1024 > > > > >>> + uint64_t start, total; > > > > >>> + struct rte_event ev; > > > > >>> + int rc, cnt; > > > > >>> + > > > > >>> + ev.event_type =3D RTE_EVENT_TYPE_CPU; > > > > >>> + ev.queue_id =3D 0; > > > > >>> + ev.op =3D RTE_EVENT_OP_NEW; > > > > >>> + ev.u64 =3D 0xBADF00D0; > > > > >>> + > > > > >>> + for (cnt =3D 0; cnt < NB_EVENTS; cnt++) { > > > > >>> + ev.flow_id =3D cnt; > > > > >>> + rc =3D rte_event_enqueue_burst(TEST_DEV_ID, 0, &ev, > > 1); > > > > >>> + TEST_ASSERT(rc =3D=3D 1, "Failed to enqueue event"); > > > > >>> + } > > > > >>> + > > > > >>> + RTE_SET_USED(preschedule_type); > > > > >>> + total =3D 0; > > > > >>> + while (cnt) { > > > > >>> + start =3D rte_rdtsc_precise(); > > > > >>> + rc =3D rte_event_dequeue_burst(TEST_DEV_ID, 0, &ev, > > 1, 0); > > > > >>> + if (rc) { > > > > >>> + total +=3D rte_rdtsc_precise() - start; > > > > >>> + cnt--; > > > > >>> + } > > > > >>> + } > > > > >>> + printf("Preschedule type : %s, avg cycles %" PRIu64 "\n", > > > > >>> preschedule_name, > > > > >>> + total / NB_EVENTS); > > > > >>> + > > > > >>> + return TEST_SUCCESS; > > > > >>> +} > > > > >>> + > > > > >>> +static int > > > > >>> +test_eventdev_preschedule_configure(void) > > > > >>> +{ > > > > >>> + struct rte_event_dev_config dev_conf; > > > > >>> + struct rte_event_dev_info info; > > > > >>> + int rc; > > > > >>> + > > > > >>> + rte_event_dev_info_get(TEST_DEV_ID, &info); > > > > >>> + > > > > >>> + if ((info.event_dev_cap & > > > > >> RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE) > > > > >>> =3D=3D 0) > > > > >>> + return TEST_SKIPPED; > > > > >>> + > > > > >>> + devconf_set_default_sane_values(&dev_conf, &info); > > > > >>> + dev_conf.preschedule_type =3D > > RTE_EVENT_DEV_PRESCHEDULE; > > > > >>> + rc =3D rte_event_dev_configure(TEST_DEV_ID, &dev_conf); > > > > >>> + TEST_ASSERT_SUCCESS(rc, "Failed to configure eventdev"); > > > > >>> + > > > > >>> + rc =3D preschedule_test(RTE_EVENT_DEV_PRESCHEDULE_NONE, > > > > >>> "RTE_EVENT_DEV_PRESCHEDULE_NONE"); > > > > >>> + rc |=3D preschedule_test(RTE_EVENT_DEV_PRESCHEDULE, > > > > >>> "RTE_EVENT_DEV_PRESCHEDULE"); > > > > >>> + if (info.event_dev_cap & > > > > >>> RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE) > > > > >>> + rc |=3D > > > > >>> preschedule_test(RTE_EVENT_DEV_PRESCHEDULE_ADAPTIVE, > > > > >>> + > > > > >>> "RTE_EVENT_DEV_PRESCHEDULE_ADAPTIVE"); > > > > >>> + > > > > >>> + return rc; > > > > >>> +} > > > > >>> + > > > > >>> static int > > > > >>> test_eventdev_close(void) > > > > >>> { > > > > >>> @@ -1310,6 +1371,8 @@ static struct unit_test_suite > > > > >>> eventdev_common_testsuite =3D { > > > > >>> test_eventdev_start_stop), > > > > >>> TEST_CASE_ST(eventdev_configure_setup, > > > > >>> eventdev_stop_device, > > > > >>> test_eventdev_profile_switch), > > > > >>> + TEST_CASE_ST(eventdev_configure_setup, NULL, > > > > >>> + test_eventdev_preschedule_configure), > > > > >>> TEST_CASE_ST(eventdev_setup_device, > > > > >> eventdev_stop_device, > > > > >>> test_eventdev_link), > > > > >>> TEST_CASE_ST(eventdev_setup_device, > > > > >> eventdev_stop_device, > > > > >>> diff --git a/doc/guides/prog_guide/eventdev/eventdev.rst > > > > >>> b/doc/guides/prog_guide/eventdev/eventdev.rst > > > > >>> index fb6dfce102..341b9bb2c6 100644 > > > > >>> --- a/doc/guides/prog_guide/eventdev/eventdev.rst > > > > >>> +++ b/doc/guides/prog_guide/eventdev/eventdev.rst > > > > >>> @@ -357,6 +357,28 @@ Worker path: > > > > >>> // Process the event received. > > > > >>> } > > > > >>> > > > > >>> +Event Pre-scheduling > > > > >>> +~~~~~~~~~~~~~~~~~~~~ > > > > >>> + > > > > >>> +Event pre-scheduling improves scheduling performance by > > > > >>> +assigning events to event ports in advance when dequeues are > issued. > > > > >>> +The `rte_event_dequeue_burst` operation initiates the > > > > >>> +pre-schedule operation, which completes in parallel without > > > > >>> +affecting the dequeued > > > > >> event > > > > >>> flow contexts and dequeue latency. > > > > >>> +On the next dequeue operation, the pre-scheduled events are > > > > >>> +dequeued and pre-schedule is initiated again. > > > > >>> + > > > > >>> +An application can use event pre-scheduling if the event > > > > >>> +device supports it at either device level or at a individual p= ort level. > > > > >>> +The application can check pre-schedule capability by checking > > > > >>> +if ``rte_event_dev_info.event_dev_cap`` > > > > >>> +has the bit ``RTE_EVENT_DEV_CAP_PRESCHEDULE`` set, if present > > > > >>> +pre-scheduling can be enabled at device configuration time by > > > > >>> +setting > > > > >>> appropriate pre-schedule type in > > ``rte_event_dev_config.preschedule``. > > > > >>> + > > > > >>> +Currently, the following pre-schedule types are supported: > > > > >>> + * ``RTE_EVENT_DEV_PRESCHEDULE_NONE`` - No pre-scheduling. > > > > >>> + * ``RTE_EVENT_DEV_PRESCHEDULE`` - Always issue a > > > > >>> +pre-schedule when > > > > >>> dequeue is issued. > > > > >>> + * ``RTE_EVENT_DEV_PRESCHEDULE_ADAPTIVE`` - Issue > > > > >>> + pre-schedule > > > > when > > > > >>> dequeue is issued and there are > > > > >>> + no forward progress constraints. > > > > >>> + > > > > >>> Starting the EventDev > > > > >>> ~~~~~~~~~~~~~~~~~~~~~ > > > > >>> > > > > >>> diff --git a/lib/eventdev/rte_eventdev.h > > > > >>> b/lib/eventdev/rte_eventdev.h > > > > >> index > > > > >>> 08e5f9320b..5ea7f5a07b 100644 > > > > >>> --- a/lib/eventdev/rte_eventdev.h > > > > >>> +++ b/lib/eventdev/rte_eventdev.h > > > > >>> @@ -446,6 +446,30 @@ struct rte_event; > > > > >>> * @see RTE_SCHED_TYPE_PARALLEL > > > > >>> */ > > > > >>> > > > > >>> +#define RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE (1ULL << 16) > > > /**< > > > > >> Event > > > > >>> +device supports event pre-scheduling. > > > > >>> + * > > > > >>> + * When this capability is available, the application can > > > > >>> +enable event pre-scheduling on the event > > > > >>> + * device to pre-schedule events to a event port when > > > > >>> +`rte_event_dequeue_burst()` > > > > >>> + * is issued. > > > > >>> + * The pre-schedule process starts with the > > > > >>> +`rte_event_dequeue_burst()` call and the > > > > >>> + * pre-scheduled events are returned on the next > > > > >> `rte_event_dequeue_burst()` > > > > >>> call. > > > > >>> + * > > > > >>> + * @see rte_event_dev_configure() */ > > > > >>> + > > > > >>> +#define RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE > > (1ULL > > > > << > > > > >> 17) > > > > >>> /**< > > > > >>> +Event device supports adaptive event pre-scheduling. > > > > >>> + * > > > > >>> + * When this capability is available, the application can > > > > >>> +enable adaptive pre-scheduling > > > > >>> + * on the event device where the events are pre-scheduled > > > > >>> +when there are no forward > > > > >>> + * progress constraints with the currently held flow contexts. > > > > >>> + * The pre-schedule process starts with the > > > > >>> +`rte_event_dequeue_burst()` call and the > > > > >>> + * pre-scheduled events are returned on the next > > > > >> `rte_event_dequeue_burst()` > > > > >>> call. > > > > >>> + * > > > > >>> + * @see rte_event_dev_configure() */ > > > > >>> + > > > > >>> /* Event device priority levels */ > > > > >>> #define RTE_EVENT_DEV_PRIORITY_HIGHEST 0 > > > > >>> /**< Highest priority level for events and queues. > > > > >>> @@ -680,6 +704,25 @@ rte_event_dev_attr_get(uint8_t dev_id, > > > > uint32_t > > > > >>> attr_id, > > > > >>> * @see rte_event_dequeue_timeout_ticks(), > > > > rte_event_dequeue_burst() > > > > >>> */ > > > > >>> > > > > >>> +typedef enum { > > > > >>> + RTE_EVENT_DEV_PRESCHEDULE_NONE =3D 0, > > > > >>> + /* Disable pre-schedule across the event device or on a > > > > >>> +given event > > > > >> port. > > > > >>> + * @ref rte_event_dev_config.preschedule_type > > > > >>> + */ > > > > >>> + RTE_EVENT_DEV_PRESCHEDULE, > > > > >>> + /* Enable pre-schedule always across the event device or a > > given > > > > >>> +event > > > > >>> port. > > > > >>> + * @ref rte_event_dev_config.preschedule_type > > > > >>> + * @see RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE > > > > >>> + */ > > > > >>> + RTE_EVENT_DEV_PRESCHEDULE_ADAPTIVE, > > > > >>> + /* Enable adaptive pre-schedule across the event device or a > > > > >>> +given > > > > >> event > > > > >>> port. > > > > >>> + * Delay issuing pre-schedule until there are no forward > > > > >>> +progress > > > > >>> constraints with > > > > >>> + * the held flow contexts. > > > > >>> + * @ref rte_event_dev_config.preschedule_type > > > > >>> + * @see > > RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE > > > > >>> + */ > > > > >>> +} rte_event_dev_preschedule_type_t; > > > > >>> + > > > > >>> /** Event device configuration structure */ struct > > > rte_event_dev_config { > > > > >>> uint32_t dequeue_timeout_ns; @@ -752,6 +795,11 @@ > struct > > > > >>> rte_event_dev_config { > > > > >>> * optimized for single-link usage, this field is a hint > > > > >>> for how > > many > > > > >>> * to allocate; otherwise, regular event ports and queues > > > > >>> will > > be used. > > > > >>> */ > > > > >>> + rte_event_dev_preschedule_type_t preschedule_type; > > > > >>> + /**< Event pre-schedule type to use across the event device, > > > > >>> +if > > > > >>> supported. > > > > >>> + * @see RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE > > > > >>> + * @see > > RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE > > > > >>> + */ > > > > >>> }; > > > > >>> > > > > >>> /** > > > > >>> -- > > > > >>> 2.25.1 > > > > >