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 66D2A43A35; Thu, 1 Feb 2024 10:35:27 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 54C1340299; Thu, 1 Feb 2024 10:35:27 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by mails.dpdk.org (Postfix) with ESMTP id CEBC840275 for ; Thu, 1 Feb 2024 10:35:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706780125; x=1738316125; h=date:from:to:cc:subject:message-id:references: in-reply-to:mime-version; bh=HP/ST1p4zNu/YIl8rLgmFwh9sYs0SnDIGtRDHzpUOHg=; b=FQtpWDqpcrav0zqrqxXPuaobL/A2XPeD4KkScJphaUEOBC/3u4Yt4s7G GC+PSTKcCT5nULYhw2ZvmKq81W5BYyHKmpUdt5JlwI2UpxcHMGNxDrgY+ 7rpvyHET2nmt9KXZyxBMxOxb94/KtMdhQs6Urc7fLsLV0ihtL5qGj5WE/ ht8DtG0CuufiWDKCd+XwaxejBIO5wsStKoWUJ4/clVkZTsciRDL5LhDi2 B9KIJIzgKVVhbfdJiZajfkLNH/Qp7sWi99IMS/T1b24MrkLeITvl1jmio W/6vl/DgFAjGkLhZWUxa6K0+0YI9TbEwF6OgRGpo2vqpINqqbwht9Qvh/ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10969"; a="11224838" X-IronPort-AV: E=Sophos;i="6.05,234,1701158400"; d="scan'208";a="11224838" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2024 01:35:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,234,1701158400"; d="scan'208";a="30548612" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orviesa002.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 01 Feb 2024 01:35:24 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 1 Feb 2024 01:35:22 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) 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; Thu, 1 Feb 2024 01:35:22 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx602.amr.corp.intel.com (10.18.126.82) 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, 1 Feb 2024 01:35:22 -0800 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (104.47.73.40) 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, 1 Feb 2024 01:35:22 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kTMFOPv2nr2WBNiloYKYPAcEZdv2uUo6XL3JxyIGPFXQ+QP4kW88Vg8aM0WsaWK3wnCco/Lu7yT7WqxgLZoAbTfBBHhnA3FnFy+riIN6JooYJv9FhauHY6QC9eUHRcBNKEwlaNv4uZh0Yxxar4Lh13+ESm+qg5OEXxDrj0msf/ENU4V+OohIYQR9oKCKhJEEP4pPAr5c+KaUm4PO0w+4mCQDawGLhfPtrzmgS+X1bvST+TiuZ5vyHEderYQ+3Y5PjUWhdNdiEO89ZYBI5ecQr9nE9nQzr+4LqV6VzEJOTdBpOPjAOFFWULJOd1wUxA5+zmbzbg1mDb/LSN3WnMwUsA== 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=0yko33fIw4mS1cFfNy5QZbHRZeqhC0v4biYYrml6B70=; b=bBiTQw363qHorZKORiyQzcOLiQljBYAhFpizsdiy+CKd0dZevin1bZwiea72o4wtrvv2HvWl7p3H/HJndPO8EoxLr5bPTSOxHw4zRfgX2I7a8fX+UJQU2Ixpt41D3yD1XfmdvmqcU4ZlzB+O6mBR22xA9KTG4D2SOvsrxEklnDEjJQsBP0Nx016jMwAAGLzi7Gr7Zar5CTq5moryo01cJhzF5n2khXi1ZLk6NSO2tSjvF20lM7m+KzEAcwTZ0OPZxg+uBI7fmGqG45lbyiXUhH/xzRV6rn9LG9e+5g5b1DnQJyHUddD9l1Da/6+CNSRBiLc9yQnap2U3AYW7akfBIw== 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 PH7PR11MB8526.namprd11.prod.outlook.com (2603:10b6:510:30a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.26; Thu, 1 Feb 2024 09:35:20 +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.7249.017; Thu, 1 Feb 2024 09:35:20 +0000 Date: Thu, 1 Feb 2024 09:35:15 +0000 From: Bruce Richardson To: , CC: , , , , , , Subject: Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields Message-ID: References: <20240118134557.73172-1-bruce.richardson@intel.com> <20240119174346.108905-1-bruce.richardson@intel.com> <20240119174346.108905-12-bruce.richardson@intel.com> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20240119174346.108905-12-bruce.richardson@intel.com> X-ClientProxiedBy: DB7PR02CA0023.eurprd02.prod.outlook.com (2603:10a6:10:52::36) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|PH7PR11MB8526:EE_ X-MS-Office365-Filtering-Correlation-Id: afa69bd0-92a6-4017-7aeb-08dc23091b66 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NzYmYEIFOQfvnX7we9rNPxK//YHGfCaA2KaziS6oEAFmZlaIXquECGN4GRH6kxJjWhXMftYMyJkDxG8za0GH1dWSyx6J1DbP703Nw0AeN7iqYvGnMbXGaQ5P/nIUzXDz0PGAWeigpt+2uY19wnOb/MMxRDmQvRjzZF7+ewP6KjRS2qrAZJv/m4oKS1DLRKfJvft5ypurKLdNtOd5jwDq/MimSaytSRSMy71ABcTMmyLxFkPrnpg9CIJ14XJEYBpDzT0leLD7MKR0dzhtUcgIlVWI1Gp8sMUe01pDdKzW8o35hsNL367fuNLHKLzfoTsuxkovwREEFlb2BETOybotiGEy8X7doH4AoQiR7ES2Fh6mdI8+dr8xlJPVSVVzu/vrNcufP9saFVIOMAfXO+6RxQfkfvz3/muXrIewsRi5XdqxhnmoGRbwlQN4I21lhy2sd9NXVhXZjBhVDjITbwSm2ASdB/vaqvkCBme4bRZKPQhlFl3lfEKuuNR3Pa5MExLsouyvTJA9Ad7DTE5Fryp4opuRw/0CYRWztpUaEG5k7MYNME+u/s3MQZ6bo9GhEf3Z 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)(366004)(136003)(346002)(396003)(39860400002)(376002)(230922051799003)(64100799003)(186009)(451199024)(1800799012)(66899024)(6512007)(86362001)(6486002)(478600001)(82960400001)(41300700001)(107886003)(26005)(83380400001)(5660300002)(2906002)(66556008)(4326008)(316002)(66476007)(6506007)(6666004)(44832011)(8936002)(38100700002)(8676002)(66946007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xBThR2gnG0JPD/N/IlDvATW46E6djYLflEuY005MGLxektpyWOTaQIyGEQ/+?= =?us-ascii?Q?uWz20E8sG2UAHjI9rFhxnWSKWFtGYXQ4MlWY75In72mfKtWbTKNSoeAHrYq9?= =?us-ascii?Q?IhHIyF7SegZJswwWH4E5MSrNsJSF8RtmoknTE5VJo9FWQ5PZ/iM8Uj32Gz0O?= =?us-ascii?Q?V4TEJJwQhpUT2XxZ8Uq315qBnxYbFanTkR0vnRzQxP6bkKIm5P4QYrwAQAWZ?= =?us-ascii?Q?vRrJkjO761L9tGnIRGQ2a/mwit6/SL5VkJDGxA3rLoMo6gjksOQEmyNsjmTb?= =?us-ascii?Q?gAcqj8GfgdbNHI0d7L5ohep2A+FxOuhpA4/9c2TK3TCOalbxW5+BU36etf6E?= =?us-ascii?Q?9B6lXphGtHb1t5wrvMePqmkZdd1sZrFNtBhNtbSN+SEepuAmhmOBr/QY1r3p?= =?us-ascii?Q?FlkZW8MuJ9hlc1Q966sx4kfDiro3+p+BDLxayj0/H1Y48SvaDw5D8M8VvKdr?= =?us-ascii?Q?dV5UA3xQaNTXa/fQojbVtKZk6sEIAqeLGBXx1xWxmjHiWaQLbNWeHP90jQdL?= =?us-ascii?Q?EL88FWJSDnW2ESF5ufzglrauncRKbysL7DGKxzOia5ZUXCG7ioZlplUuyFhN?= =?us-ascii?Q?qgnf33vImbV7h3UH5j8xaykAQfCTeJmewaofgWy87gac0c3DG6nNaZfJIupR?= =?us-ascii?Q?bkf4IC6ebc6dZdjfSYniZXzEZP8KsPDLcZ121fSP54cjsCBhpdl1Ax9hGGVl?= =?us-ascii?Q?zmnNsmWlR+YCCKLnqJg8C5oCPuMDONF+mfdtDBXtP4gP2k1+N+kuCCY17USe?= =?us-ascii?Q?yPkXClvvar19HbigJgDM9SNVWgLw3CQCC+2dWlR5nVTIVhaqFu1rVSKTNEYI?= =?us-ascii?Q?o5SsKbkaR7sda05XDrb/Met/M5WSfLkMluQLInT7LT/v70XkbtBYojHKqyro?= =?us-ascii?Q?6/piY411u37hTc/+LFNbi6qVTEqT1t5TvIzpeF/sdt6WcUPaENwMnlcJctPz?= =?us-ascii?Q?t+EmqsD6tMVM5kdUV2BcHIq2jJC8CbMYsv2Bor1qnT8IT6og/vANFb31Zb3m?= =?us-ascii?Q?nRz+e7aDSmP4FksEgSq38jz9o9fAqwAiNUPfQhA4iftJw39f1cs1du+TZ7eV?= =?us-ascii?Q?8BYXN+L03wwXefoC9fQd5FXQ4z9vT16alO7fdE012dJGiOrDh9EkM0FrF5mM?= =?us-ascii?Q?mJziCGKCF+fysAVI7n2wkiN6hEmFD8AuAywrsJDarRwTcqMkoOg+bopGPjkS?= =?us-ascii?Q?5rkYpAFxzWkEf3oAEmPB7m7JZzZiOZGSEu8FRh6s3Yh92AWUPGcm/CuNsDEP?= =?us-ascii?Q?DSPiWEP/xHnr7mO7cfwK9UvN5WBxm4bAn7KK2h1ZubdcdEprLPBAWRjTRNq7?= =?us-ascii?Q?35bz2cex8mVF3Nl6HZlYtmqwF1/Qy+jLgWtuO8g+tByqmjUsx/108bY4QdR0?= =?us-ascii?Q?HsBcruyqc99EJZiUw6f2WjfpdGR+ocsQJia5SpwaJ1An1JYA0Y+i9AQc7v7U?= =?us-ascii?Q?lDWNhTjlXq7cNEErqv9jkkJW4RM51uHveLluob6dKKAPBIDMFjCjkjjJtfd9?= =?us-ascii?Q?LOSmV77FPIlrvDL2649563QNxuClohCcf+ZUJ3Ov9H9ahq+LMWf7Cf87W3K4?= =?us-ascii?Q?mCfgBunvuB9i14TnLRFkPZ77Zf3zvAQa4BxUtF2hNJ+fRQUjEiwq5EHhn2o/?= =?us-ascii?Q?xA=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: afa69bd0-92a6-4017-7aeb-08dc23091b66 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2024 09:35:20.2957 (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: 4fAVEChTUbxSpTsQXMebqS1OFVJaXIeYC97siMAs9PaeC4FfBbnu/0/ZqpdESn2lENx+ITKZWBUX29/kLROrQCIOPA8p/8gPwHsTcUs9IiM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB8526 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 Fri, Jan 19, 2024 at 05:43:46PM +0000, Bruce Richardson wrote: > Clarify the meaning of the NEW, FORWARD and RELEASE event types. > For the fields in "rte_event" struct, enhance the comments on each to > clarify the field's use, and whether it is preserved between enqueue and > dequeue, and it's role, if any, in scheduling. > > Signed-off-by: Bruce Richardson > --- > > As with the previous patch, please review this patch to ensure that the > expected semantics of the various event types and event fields have not > changed in an unexpected way. > --- > lib/eventdev/rte_eventdev.h | 105 ++++++++++++++++++++++++++---------- > 1 file changed, 77 insertions(+), 28 deletions(-) > > #define RTE_EVENT_OP_RELEASE 2 > /**< Release the flow context associated with the schedule type. > * > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC* > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ATOMIC > * then this function hints the scheduler that the user has completed critical > * section processing in the current atomic context. > * The scheduler is now allowed to schedule events from the same flow from > @@ -1442,21 +1446,19 @@ struct rte_event_vector { > * performance, but the user needs to design carefully the split into critical > * vs non-critical sections. > * > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED* > - * then this function hints the scheduler that the user has done all that need > - * to maintain event order in the current ordered context. > - * The scheduler is allowed to release the ordered context of this port and > - * avoid reordering any following enqueues. > - * > - * Early ordered context release may increase parallelism and thus system > - * performance. Before I do up a V3 of this patchset, I'd like to try and understand a bit more what was meant by the original text for reordered here. The use of "context" is very ambiguous, since it could refer to a number of different things here. For me, RELEASE for ordered queues should mean much the same as for atomic queues - it means that the event being released is to be "dropped" from the point of view of the eventdev scheduler - i.e. any atomic locks held for that event should be released, and any reordering slots for it should be skipped. However, the text above seems to imply that when we release one event it means that we should stop reordering all subsequent events for that port - which seems wrong to me. Especially in the case where reordering may be done per flow, does one release mean that we need to go through all flows and mark as skipped all reordered slots awaiting returned events from that port? If this is what is intended, how is it better than just doing another dequeue call from the port, which releases everything automatically anyway? Jerin, I believe you were the author of the original text, can you perhaps clarify? Other PMD maintainers, can any of you chime in with current supported behaviour when enqueuing a release of an ordered event? Ideally, I'd like to see this simplified whereby release for ordered behaves like that for atomic, and refers to the current event only, (and drop any mention of contexts). Thanks, /Bruce