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 8FE2D43B57; Tue, 20 Feb 2024 18:39:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 608C0402A7; Tue, 20 Feb 2024 18:39:36 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) by mails.dpdk.org (Postfix) with ESMTP id D8CBE40289 for ; Tue, 20 Feb 2024 18:39:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708450776; x=1739986776; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=GPb5ljQD5ub9JntND5iJFaipAPBi3EvrFYKbdNNp72M=; b=XjcPEv0vBFcLCcrHYUUwZ9Na8Bqx6dKDqn+9NpOOQu/1MLJPrI5D+0Kb RKkFKWNuNEMd8bUB0f+Tt2EDJTHFzSygtyQRHJ6IIZOEUUjYgW573QwQP fYEq20ElnJyW2Zy9GwbQULm9gL1Hgo0WWBPRFCd07Wno2znLApNKLrC4I rCRHNrlfI+L7l60KnSF7YGV9orM24dHvqGT5Qn8jeL5T34AQ7PZXxLmyV f3IqwXDXH4m+fHsDTMQlz9NPq/bVVV9qBc/WDgYHNib8w19fUcjarrZX+ nParxtBzqi9KjRF2zpAj3ihDRSxl7zSThrVwjjMA523eRNGDLPeF7pcHc Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10990"; a="2442607" X-IronPort-AV: E=Sophos;i="6.06,174,1705392000"; d="scan'208";a="2442607" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2024 09:39:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10990"; a="913114485" X-IronPort-AV: E=Sophos;i="6.06,174,1705392000"; d="scan'208";a="913114485" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga002.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 20 Feb 2024 09:39: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; Tue, 20 Feb 2024 09:39:24 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) 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; Tue, 20 Feb 2024 09:39:24 -0800 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.57.41) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 20 Feb 2024 09:39:24 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hM+a503ZjVK4ZA/ilUcyS41wU7CraMXtM++JSt8Nl4XVvfD+0gVRWE6Hek+Wfnw/A7zZz5uMCfV86DMyPzAiKPP6srb1Mxfq/gOoYH+6UxzWMjAarpGkH+sPNYrOgwtNbjUrrEc8MMwRc9mzhMXjc8vV7yqX5ZLLwtUl2eyqtHyOu/6FOP42QWOeujCuHXNFmykCJdaDKXxAilI4OsRtb7X8icS959y49Iyf8/NCg8fzMMML73fJsgWv3aFzecbv5Pwy2SJrsvMYMpQKTG9Vm14VVD2qc5PdWPe0rH+bowe/YwX70UV8ZTPEC4Gv/Y6faYPX/rJGZj7ahNJVs0poZQ== 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=kSWIP1hgC1W3dtoeD3NopA0CrfQWv5CUnegIUDfNyAQ=; b=bRA7x/aWUrO4af8lc9a5XGDNEZlr0bagDT2R9NvZWAoGXz/Q/r1b5hitD6KIOUf6qMC2GuGV+0DoMi5TFC52mipMKxXX3LIuxxAFN11z+ieWgn3MyhagyNtutfRiWjFskagJG6CTqWocWWPbKb/6303kKTPQeYYAG2f1DVniLY2DmaIxAwg9NXkVqwHspBIBTw17ZJQpPMPv5vfQItaydb+AB2/Hk/lqvb3sw+5KhdxgdlmYxjHpM+iJl4nBB7/PSyddR2N1yqAYNeWjdnonCaOESJODRHIsfOqGAG2edHV/odnwujIzE7JZiDOEdcpxLe26kTmqraoW9m78qzbLfA== 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 BL1PR11MB5256.namprd11.prod.outlook.com (2603:10b6:208:30a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.39; Tue, 20 Feb 2024 17:39:21 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::d10:3009:a8d3:1d2e]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::d10:3009:a8d3:1d2e%7]) with mapi id 15.20.7292.036; Tue, 20 Feb 2024 17:39:21 +0000 Date: Tue, 20 Feb 2024 17:39:15 +0000 From: Bruce Richardson To: Jerin Jacob CC: , , , , , , , Subject: Re: [PATCH v3 10/11] eventdev: clarify docs on event object fields and op types Message-ID: References: <20240119174346.108905-1-bruce.richardson@intel.com> <20240202123953.77166-1-bruce.richardson@intel.com> <20240202123953.77166-11-bruce.richardson@intel.com> Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: DB3PR06CA0034.eurprd06.prod.outlook.com (2603:10a6:8:1::47) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|BL1PR11MB5256:EE_ X-MS-Office365-Filtering-Correlation-Id: 94e79433-8e59-46a8-4bc6-08dc323adf28 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wl6Ls0xImk/g90FfBsK2KQMHKVo8g4fs5TTraF+8qraipduHTyXs//cNrggDQhz4joITcgD2FJhbQxuYKbhDmu3T5NLAer+kxwhOwGtdVewpn9FNz0/oVMYp2uJOZoiFx4ZHfOybXLCq0TAhxh5ymJ1rpskrv5j+4E1S8mXwlhWfJqOv9YXmB2IOk7jyEbSh4Jw+DTfQHlsumFAMjNigkzBNGYkopIE0m+ApXzThNVHBF4AxBfn7y4qdWGFc0UJwsMBetQR0bNyQFqTwo89dMJOacYBH2/B5DIvD3CM63QNIeJMzzdM8+Y0MP+DlQB1vWjuJxJAwoeffPhAN0S+oxoOrJmyT0/N4jFzG+491JmVueYRnY56AvR4RPHwlGA7L4SOJCQMK9LZ2gjw2By00cEYLdTIAWrp+nyR4WswIGcdsdCxYV7B1FGSPaGjH6On+NTDWqeai0wuKCMIrleqkWox/OHJgvqmX/F9S4DeUNtgZJPoApXL6TrGCBwx8y16vtjgAtR9UP4ixystCBguYKQ== 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); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MUd2bWxLRWdBYkcrR2hLb2FsOHJLMzVVam0yTnZuWW1rbm9hSnpLZm56VTZK?= =?utf-8?B?anQvWm9sbnlseHVwZ3RqQkVjMHVIU2lVaG13dFB3dWhIeCtJVi9xNXgyOVkr?= =?utf-8?B?bXVJU29HVlNaWnJmbnMyREwyQU1XN1YzUWgzZ3FPbUcwR3ptYjZFWnlTWVEx?= =?utf-8?B?SDNzWXlJZE1LL2FQMUpRZWdwZ3NSUkdjMS85UFBFWFFWQVRuVk9FNEhkUUtL?= =?utf-8?B?ZTBRWTgyNGpWZTBjT0h5bWhUR01HMnc3aElvMUdDZzBOOU5VWERxQW5ZYVgv?= =?utf-8?B?T3RxL0dCcXlOdkEzNWtYeTh0QVl1dG5sNEhPUE45c2dtaWhOTHNhY2E4dVRM?= =?utf-8?B?Z3ZwUGpyK0ZibUhLNGJpUE5nRzRCZjdhVGtMSjA1Q2VuczVQMXBmMWoxQzJo?= =?utf-8?B?TjlqVk9WWlV6RWNQTS9OTEZzM3dLR250bFFEbkpoa3JNbjRHNy8rRWNTdWho?= =?utf-8?B?WlB4VjJKQm1aM2NuYTlxRG5UTHhSbGN3M0dhdE5zMUZtOEZEQTRhd0tiMnE3?= =?utf-8?B?WUdiN2lkYUVyUlRWR3B5Z2xyaDhBdDlKY3lVdVo0cmVlZEVzSm4yeW9ETk9X?= =?utf-8?B?Z2VJREtxY0hMajZCVlFIcnE1VGl2QUdYSnNyNWtnWExJWjN0TjVuQm5GdGFl?= =?utf-8?B?L3RES1FvNWVIWE5IbEw3eTUxNmdBbmdKOVpHZVpXZlpDcjVJVzZCNG8xMWFG?= =?utf-8?B?NlhrdXlEaGhqMVVvNW0vUGNxWDZwQnFhbWJDTWM5cWpQanZYK1FWYlJpTTJF?= =?utf-8?B?dStsS1NVcTAxejdWRVlvWFBkN3RmdWxNSElFYnNSd2RpKzNKL3NwQ3c4VXFn?= =?utf-8?B?dlJFanQ4T3JGMUFMUUZ5clpYcnFjdjZGc0tHT1lPR01BV05pWjc3dmVjQm5q?= =?utf-8?B?WExtS0hVYXBLMHRMdlRCSnBFUnRoelM4MFFKOGhCQ1VNL3hBZDlXTS9IVEJW?= =?utf-8?B?cjZIWUtZRDNDY0lMS1JRUzdtUFYxUXJvTkpSNGFBcTNnb1dKS0Q1ZWc2Sk9I?= =?utf-8?B?dWUxY1pUSGZXY0wrd2hLTWRNYmN4TWlRU2lPcnhMSWQxald4RnVRY2pZQ2hM?= =?utf-8?B?czBGU01Ha3lTbmpPZGhvRjgwZ1VpNllFOXZkb1BKbTRZUGJXcHZYMXgzcVRa?= =?utf-8?B?QXZ1SHFvUnVIV0Z5aHI5NUJOWW5MTkhHNWgyRWgwYmwzUkVwRml3QkVOUXNw?= =?utf-8?B?b0tGQWZIV2lrOXRqOWw5ZFY3UDg0R3hLUk5tVFI1ckxpd3M2UHVrWXVlM2pL?= =?utf-8?B?bXhaMUN3ejRyOVV2SWNaM3lKZWVmUm1Ialo4WFkwK3VmQ01MdUxJNWJyekQ0?= =?utf-8?B?UHlReE8vcHkrdGtacmxoN0NyNy9zZFVFaDdkVDQvejJEQ1krZFZqWDI5MEtC?= =?utf-8?B?NE5Pc1lCdnZBZWY0c09uM0Z0a1ZlQmlsUm03eHQ1RklrTTZpaWxHeWIwZmti?= =?utf-8?B?SGFMNWNiQkNCTDMzYnFPRTdPbDN2MXJhb3dHWlZneUhVZExzSVl1L1RlTDlL?= =?utf-8?B?akJZdk8vNG1ZOUVCMk42NWxaakhnejBDT2FoZ3NPczg1SE9zbjQxUHBULzZs?= =?utf-8?B?aTBJNzcrSG8wYUV3R2hremwxNVJlZW5sUnJnWU45MHVaY2w0ZlJwTUpmYlhv?= =?utf-8?B?WkFMUzZpNFNvbGtCKy8wZlhaT1BhemhvVkdHQ2RXRXZEYTNlb3hlQTZqMlBI?= =?utf-8?B?c0hjMk5RczFmQit2cUxIWVRRYmdzbFd3L3A2QnlPK1FFekVLbUhKcFhJbTBN?= =?utf-8?B?YWVibG9FdU54VkJqb2cxV1NtREJpT3Z0VzNueEI0ak1adEdqeThpSmtQbyta?= =?utf-8?B?TWZ3SVRPekQ2bWN2czg0MS9vZHNhRGNxOHVJaEw3TnowK0drYVVJZVI4Mlh1?= =?utf-8?B?aWp3bm5jVGV6WWMvcGxWL1oxNUJRTXVkVTFhZ3JKS3JQTmpqQnM5ZytKQTlE?= =?utf-8?B?V1N4Z1kxTDlnTlRKMTQrWC9qdVl2c3hzU1Z3eWRIamdPZGJmNU9LTWtLcnha?= =?utf-8?B?b0ZDYlM2TnZGYUMwVFpzYnc1YzlRUW5uSmNwTzUwYWx5OHZ5UzBGUExNVTN6?= =?utf-8?B?Ulp6QTNOakx3d3RFTUxhNWZ0cGFzMUxNU1hCZ2pyd2JIZGl6N2dEK2w2by83?= =?utf-8?B?TFlWMFRKdCt4cUJPZ3pIbHJmU0d6clB3TTd4blNiMFByNkVQL0t2ZXA3VFZw?= =?utf-8?B?MlE9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 94e79433-8e59-46a8-4bc6-08dc323adf28 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2024 17:39:21.4717 (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: /6hnEgdq73mpmoZJNMGAueaqyYkln65/8r9Bl4pPXLCrvhJO5T2Rms63STgGISfk/bJFJGvYWBzDFruMOdUVu90rjOS2PHS20sWd5wn6UuQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5256 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, Feb 09, 2024 at 02:44:04PM +0530, Jerin Jacob wrote: > On Fri, Feb 2, 2024 at 6:11 PM 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 > > --- > > V3: updates following review > > --- > > lib/eventdev/rte_eventdev.h | 161 +++++++++++++++++++++++++----------- > > 1 file changed, 111 insertions(+), 50 deletions(-) > > > > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h > > index 8d72765ae7..58219e027e 100644 > > --- a/lib/eventdev/rte_eventdev.h > > +++ b/lib/eventdev/rte_eventdev.h > > @@ -1463,47 +1463,54 @@ struct rte_event_vector { > > > > /* Event enqueue operations */ > > #define RTE_EVENT_OP_NEW 0 > > -/**< The event producers use this operation to inject a new event to the > > - * event device. > > +/**< The @ref rte_event.op field must be set to this operation type to inject a new event, > > + * i.e. one not previously dequeued, into the event device, to be scheduled > > + * for processing. > > */ > > #define RTE_EVENT_OP_FORWARD 1 > > -/**< The CPU use this operation to forward the event to different event queue or > > - * change to new application specific flow or schedule type to enable > > - * pipelining. > > +/**< The application must set the @ref rte_event.op field to this operation type to return a > > + * previously dequeued event to the event device to be scheduled for further processing. > > * > > - * This operation must only be enqueued to the same port that the > > + * This event *must* be enqueued to the same port that the > > * event to be forwarded was dequeued from. > > + * > > + * The event's fields, including (but not limited to) flow_id, scheduling type, > > + * destination queue, and event payload e.g. mbuf pointer, may all be updated as > > + * desired by the application, but the @ref rte_event.impl_opaque field must > > + * be kept to the same value as was present when the event was dequeued. > > */ > > #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* > > - * 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 > > - * an event queue to another port. However, the context may be still held > > - * until the next rte_event_dequeue_burst() call, this call allows but does not > > - * force the scheduler to release the context early. > > - * > > - * Early atomic context release may increase parallelism and thus system > > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ATOMIC > > + * then this operation type hints the scheduler that the user has completed critical > > + * section processing for this event in the current atomic context, and that the > > + * scheduler may unlock any atomic locks held for this event. > > + * If this is the last event from an atomic flow, i.e. all flow locks are released, > > > Similar comment as other email > [Jerin] When there are multiple atomic events dequeue from @ref > rte_event_dequeue_burst() > for the same event queue, and it has same flow id then the lock is .... > > [Mattias] > Yes, or maybe describing the whole lock/unlock state. > > "The conceptual per-queue-per-flow lock is in a locked state as long > (and only as long) as one or more events pertaining to that flow were > scheduled to the port in question, but are not yet released." > > Maybe it needs to be more meaty, describing what released means. I don't > have the full context of the documentation in my head when I'm writing this. > Will take a look to reword a bit > > > + * the scheduler is now allowed to schedule events from that flow from to another port. > > + * However, the atomic locks may be still held until the next rte_event_dequeue_burst() > > + * call; enqueuing an event with opt type @ref RTE_EVENT_OP_RELEASE allows, > > Is ";" intended? > > > + * but does not force, the scheduler to release the atomic locks early. > > instead of "not force", can use the term _hint_ the driver and reword. Ok. > > > + * > > + * Early atomic lock release may increase parallelism and thus system > > * 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. > > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ORDERED > > + * then this operation type informs the scheduler that the current event has > > + * completed processing and will not be returned to the scheduler, i.e. > > + * it has been dropped, and so the reordering context for that event > > + * should be considered filled. > > * > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_PARALLEL* > > - * or no scheduling context is held then this function may be an NOOP, > > - * depending on the implementation. > > + * Events with this operation type must only be enqueued to the same port that the > > + * event to be released was dequeued from. The @ref rte_event.impl_opaque > > + * field in the release event must have the same value as that in the original dequeued event. > > * > > - * This operation must only be enqueued to the same port that the > > - * event to be released was dequeued from. > > + * If a dequeued event is re-enqueued with operation type of @ref RTE_EVENT_OP_RELEASE, > > + * then any subsequent enqueue of that event - or a copy of it - must be done as event of type > > + * @ref RTE_EVENT_OP_NEW, not @ref RTE_EVENT_OP_FORWARD. This is because any context for > > + * the originally dequeued event, i.e. atomic locks, or reorder buffer entries, will have > > + * been removed or invalidated by the release operation. > > */ > > > > /** > > @@ -1517,56 +1524,110 @@ struct rte_event { > > /** Event attributes for dequeue or enqueue operation */ > > struct { > > uint32_t flow_id:20; > > - /**< Targeted flow identifier for the enqueue and > > - * dequeue operation. > > - * The value must be in the range of > > - * [0, nb_event_queue_flows - 1] which > > - * previously supplied to rte_event_dev_configure(). > > + /**< Target flow identifier for the enqueue and dequeue operation. > > + * > > + * For @ref RTE_SCHED_TYPE_ATOMIC, this field is used to identify a > > + * flow for atomicity within a queue & priority level, such that events > > + * from each individual flow will only be scheduled to one port at a time. > > + * > > + * This field is preserved between enqueue and dequeue when > > + * a device reports the @ref RTE_EVENT_DEV_CAP_CARRY_FLOW_ID > > + * capability. Otherwise the value is implementation dependent > > + * on dequeue. > > */ > > uint32_t sub_event_type:8; > > /**< Sub-event types based on the event source. > > + * > > + * This field is preserved between enqueue and dequeue. > > + * This field is for application or event adapter use, > > + * and is not considered in scheduling decisions. > > > cnxk driver is considering this for scheduling decision to > differentiate the producer i.e event adapters. > If other drivers are not then we can change the language around it is > implementation defined. > How does the event type influence the scheduling decision? I can drop the last line here, but it seems strange to me that the type of event could affect things. I would have thought that with the eventdev API only the queue, flow id, and priority would be factors in scheduling? > > > + * > > * @see RTE_EVENT_TYPE_CPU > > */ > > uint32_t event_type:4; > > - /**< Event type to classify the event source. > > - * @see RTE_EVENT_TYPE_ETHDEV, (RTE_EVENT_TYPE_*) > > + /**< Event type to classify the event source. (RTE_EVENT_TYPE_*) > > + * > > + * This field is preserved between enqueue and dequeue > > + * This field is for application or event adapter use, > > + * and is not considered in scheduling decisions. > > > cnxk driver is considering this for scheduling decision to > differentiate the producer i.e event adapters. > If other drivers are not then we can change the language around it is > implementation defined. > > > */ > > uint8_t op:2; > > - /**< The type of event enqueue operation - new/forward/ > > - * etc.This field is not preserved across an instance > > - * and is undefined on dequeue. > > - * @see RTE_EVENT_OP_NEW, (RTE_EVENT_OP_*) > > + /**< The type of event enqueue operation - new/forward/ etc. > > + * > > + * This field is *not* preserved across an instance > > + * and is implementation dependent on dequeue. > > + * > > + * @see RTE_EVENT_OP_NEW > > + * @see RTE_EVENT_OP_FORWARD > > + * @see RTE_EVENT_OP_RELEASE > > */ > > uint8_t rsvd:4; > > - /**< Reserved for future use */ > > + /**< Reserved for future use. > > + * > > + * Should be set to zero on enqueue. > > I am worried about some application explicitly start setting this to > zero on every enqueue. > Instead, can we say application should not touch the field, Since every eventdev > operations starts with dequeue() driver can fill to the correct value. > I'll set this to zero on "NEW", or untouched on FORWARD/RELEASE. If we don't state that it should be zeroed on NEW or untouched otherwise we cannot use the space in future without ABI break. > > + */ > > uint8_t sched_type:2; > > /**< Scheduler synchronization type (RTE_SCHED_TYPE_*) > > * associated with flow id on a given event queue > > * for the enqueue and dequeue operation. > > + * > > + * This field is used to determine the scheduling type > > + * for events sent to queues where @ref RTE_EVENT_QUEUE_CFG_ALL_TYPES > > + * is configured. > > + * For queues where only a single scheduling type is available, > > + * this field must be set to match the configured scheduling type. > > + * > > + * This field is preserved between enqueue and dequeue. > > + * > > + * @see RTE_SCHED_TYPE_ORDERED > > + * @see RTE_SCHED_TYPE_ATOMIC > > + * @see RTE_SCHED_TYPE_PARALLEL > > */ > > uint8_t queue_id; > > /**< Targeted event queue identifier for the enqueue or > > * dequeue operation. > > - * The value must be in the range of > > - * [0, nb_event_queues - 1] which previously supplied to > > - * rte_event_dev_configure(). > > + * The value must be less than @ref rte_event_dev_config.nb_event_queues > > + * which was previously supplied to rte_event_dev_configure(). > > Some reason, similar text got removed for flow_id. Please add the same. > That was deliberate based on discussion on V2. See: http://inbox.dpdk.org/dev/Zby3nb4NGs8T5odL@bricha3-MOBL.ger.corp.intel.com/ and wider thread discussion starting here: http://inbox.dpdk.org/dev/ZbvOtAEpzja0gu7b@bricha3-MOBL.ger.corp.intel.com/ Basically, the comment is wrong based on what the code does now. No event adapters or apps are limiting the flow-id, and nothing seems broken, so we can remove the comment.