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 C89CE43BE1; Mon, 26 Feb 2024 07:49:27 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 98044402BA; Mon, 26 Feb 2024 07:49:27 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id BD34640144 for ; Mon, 26 Feb 2024 07:49:15 +0100 (CET) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 41Q6jG9A005140; Sun, 25 Feb 2024 22:49:15 -0800 Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) by mx0b-0016f401.pphosted.com (PPS) with ESMTPS id 3wfgun3yce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 25 Feb 2024 22:49:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GfGR5AXW3tY7agTEVRjM48yzIKc9ROx95ChS1tnqWlKPyrigQ8lEcJOk0vVu2PKpm79WhKq37HrAEw+6n7A5hgQnJDYF1sjDYVx5X1IeCATKa5po3nYZirGQG+JsVj2WRnfDTWfII1nDysbGOOBfwin+kBcRHHmcHkvi/ybNirOc3cc1uo7MRVodCZ84q2o6cfqhIS8HNSykZUJkjSrlh4L9vqc+h+uAI/XQ/M8ge5ET89ICEuMLlnz7W4lQCWTDyxTt6QvkIew5BisJynD72q4UvHwGtRawc0yxVtJKGVVVLz5uOA3lDCWkTISNzqHKQlEi+j1DVbJun7NfNNfxMQ== 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=49OxA2Jig8JkXirsrBvjMslnIB5+KuViH40tClek7lM=; b=nhSGxeirJNPzgyqvlNKQJXbZbwYCXlO6+JvM2xW/RV1nTQzGHYeDIjidhtvYrOTXK2Uw2YDfIzcX2d3QzDZ79R8kgb2IC4SxYKMYgGlLfEmRVqWMaRcdi1KwWN0BAvtiiMCu0n/TAOxxvjGNAV0NqeuEY2nTrgGlZMWbMKeFvdzsfjrsDUHGVQiYPLOfq9eexWBIuRmiPyfAcSOiGWEEVLC2rRsW2WudoGb2Op5t6hKK4syHiS3RqAwJDtPWWdU48vN2d0dCta+Xky94lMb2sv4Ro0jHNe0PcT7g8F6lfTnTCuaq2qQRKinVUXARCQwrO5mdGfoWLUo7FxFSrY9AKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=49OxA2Jig8JkXirsrBvjMslnIB5+KuViH40tClek7lM=; b=DsLTZRuasGp31m4fzpAGEoSfEzhhg5OAYSlzm3aPcE5rgmHwy2W6jIlf2LlHIOBRzTJZ/wrKGsmNfH416fwgQOy7S6NZYsaBLVH9QTRj/rCM838c7jHAyH8BqPL3b9qHn4CuXZzAaAHBSIlxWW6tJtbH8142TxaLbmeeFSCrNkg= Received: from PH0PR18MB4086.namprd18.prod.outlook.com (2603:10b6:510:3::9) by MN2PR18MB3461.namprd18.prod.outlook.com (2603:10b6:208:26f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.34; Mon, 26 Feb 2024 06:49:12 +0000 Received: from PH0PR18MB4086.namprd18.prod.outlook.com ([fe80::baf5:a4b6:7776:10f4]) by PH0PR18MB4086.namprd18.prod.outlook.com ([fe80::baf5:a4b6:7776:10f4%6]) with mapi id 15.20.7316.034; Mon, 26 Feb 2024 06:49:12 +0000 From: Pavan Nikhilesh Bhagavatula To: Bruce Richardson , "dev@dpdk.org" , Jerin Jacob , "mattias.ronnblom@ericsson.com" Subject: RE: [EXT] [PATCH v4 09/12] eventdev: improve comments on scheduling types Thread-Topic: [EXT] [PATCH v4 09/12] eventdev: improve comments on scheduling types Thread-Index: AQHaZLFsqA+VUESXZUGydQaL+kGQB7EcNmIw Date: Mon, 26 Feb 2024 06:49:12 +0000 Message-ID: References: <20240119174346.108905-1-bruce.richardson@intel.com> <20240221103221.933238-1-bruce.richardson@intel.com> <20240221103221.933238-10-bruce.richardson@intel.com> In-Reply-To: <20240221103221.933238-10-bruce.richardson@intel.com> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR18MB4086:EE_|MN2PR18MB3461:EE_ x-ms-office365-filtering-correlation-id: 7a9c2ca9-fca3-4e4d-3ec5-08dc36970a98 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rIvaoRNwD2OaNSZT+R7dq8adl/XZmPfIU/LnCSxUHt7TDqhSVnVM0RqHbNCMq5ZP4DvJBXtypKLhbz/7JmLTOh+QyWRtAJH/CpXQQ8ILQIjnw2xjwumwgZpkDgnz+E4SIHcr15xiq08GQcUym6utkvSsdYR1VFGeqqdkwNxqXo2tcjQtOoF8To5jNeLj6fqm0M7wbATRKUUavZ6cMyc+SDSLp0Fi3Tljhob11ccfvEXGpawiH7YWrro/oS/72pafFd4zbyVgsmweCOGdqYmCC21VGL1aspxKsDDq8W77HkdBDIDatVeKSfyoeXWP43gYyEIW0ppX7WPOr8mj0SOcFOgklTmzUda3evRXf3kJiVZAME5hFzLIcxNvv505YlGzjbVlyDp+OqiZgDgjqgx3FJGLCUMBowoloPALyHslZFWakH0XdDlkWBLBsGRKd6dqfyDcrMCWhQjrkqEufz8yd1riryJqQKMse3J6NMmqlGcdXfbZI4Dm7ej9KpN/2y1ZnQavDW4LkgQSMTBDT6h6cvWIcgX7scU1KMEYW5vx1nu6CrPTvB3kKkbEKXHa+bxzrtLipzlFG9GpoasVMpoqcCPrAC10705uUabL/T/No/4WAAlJY0O1fjfQi1iQCyFAWirTL9JA9QtzOyo9+YO3swb7OMhkW0xc9gTNbXLwl3s2iMSlLfnlQIFN0BRBIYTXO0OJaI6VzFn9szTGi75yaG9U3NIjCx/wq8oZrapPQc0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR18MB4086.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(38070700009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?1GH8hP8MUl+mjSray9dGrf1+hnoQKpnB7esFi6Hg8VlqaetMK/23jSFAJ+cg?= =?us-ascii?Q?JIf2nM5U2G5zBykXciAtllhgejROaF3DG7K2K4ltYmJBVf3od4RH8Tf+L40q?= =?us-ascii?Q?TcAYWwR7n0DgIGtyUBHQAb5ZEY+Y2PcFmryLMZK4+YSyyzpvUvWIobSSoFBL?= =?us-ascii?Q?u6fdio7Ub26TtLdZy+JhqyX1VTSm70nzG5PAmEi8Vszd7rxiFBjZ74HViryZ?= =?us-ascii?Q?xUmFUgRo6l7QKT8ULudCVDndSsK0Wi160kBtj8L6Y+wXIewz8mZ82SYH9n9A?= =?us-ascii?Q?rzqWUJ+e/Ee92Eu64nSSQc1QScu4RCkPWHvr8ivu3b2gzqCkCr14CBNXMdxk?= =?us-ascii?Q?So+h+6ZKrdBbYcnuom2U/UDR/hOD0Ozfr7UDxOm+gm4dXkmhtRjWe9NoLCks?= =?us-ascii?Q?6dS/fv7d8SxUzej1DDEWevoNWoyZxnSumhjGw5lvD89M0tDPECVGpnV7GWKk?= =?us-ascii?Q?610DqHLK4hrLSuul5ChqyNSNcZgXw8ZpT3hY1Jrb5hoZdJ79OPF0VLjHo9DZ?= =?us-ascii?Q?4m0P9E16QlnQIsiIuU/WDHmy6emjwf+K10rgSClaokjYvujUOdriE/otDMi/?= =?us-ascii?Q?QD9ZQ+XCr2LfC2atOa5GFwc9UO32MDssTcsOLUuY1Jr/sUwDoT+7P8opvaPu?= =?us-ascii?Q?+f/uE25QW3cdnqqrJGZhHcxJqNOCXkEEEHmT6X6shBrz77jqdyp2eoo376Me?= =?us-ascii?Q?U5PRbcn3C6PyEVb8lZQuhnfiySelSNOG8CuT/eTRHwPv4ecxYF33G7z7EHLz?= =?us-ascii?Q?/n3hxMpjUUmi0xKR60vHekVHgjfUX5gRoO4mhdYLFlHGwvRnmgcYH1BhdC63?= =?us-ascii?Q?csdi9geF+H0/RXyuG5VAkc8hBk77AOBp2ICn6uQYReGPAg0W//n7uYc4IZFQ?= =?us-ascii?Q?iDYBe3sT8yvmHKOT7AklLfVpOIkeI4T1ZYikzR35/FswUCd2QQK7YnLfMdev?= =?us-ascii?Q?9wuBpS8oFJS5eCA0KgbGKX2QaL69/l/wCVCJjBKytvbiMuO1m2M1GXwFtohd?= =?us-ascii?Q?OZTWF+ckLdZgQWQEniZCkkQ+VHynrx0NaSfULkkr80N3jXCqf763s9oS1OXr?= =?us-ascii?Q?16B6Kj9c3x+f8y/og5oAC8NcivwCEXDqOKpeEVxxD6Lxvb5gb+ByjMwsVfo+?= =?us-ascii?Q?Qu2jQkbxMwiBdCE2JWptSyzHn2BKKJTB3YOwhOhZw5GFGKgvK/OQR7q4+c4v?= =?us-ascii?Q?tUkYlNl5hPcUKwuJvOFDvaziKcAOaldYvp+9m2SjcBAIAIgtgQeAuwam9SFT?= =?us-ascii?Q?85/hay69dv+aYe+vvjTIm11YcKNOhe2zHMq+UiNdsgOGprX4MOacnWs4arNB?= =?us-ascii?Q?DKs+xyYnP9Z3wfL1/YnShxLvoa9eOMb3to5IQpvF2z8AbST8b7ZB8RQ1hjNR?= =?us-ascii?Q?YKYPmgK/XDacn2Ah67ZYbi6KVHnkMHJeqiB+euYkWFdPduemkBVrT4Xm2Wax?= =?us-ascii?Q?mRxci2Lvu7wKqvVxS7M0aHql4TdJkmTIhzW8K3b54bspDXakeiKNAu7pE6hL?= =?us-ascii?Q?UylUi8GEkmgFyszWxmIFg4D0pUS3gS56RUBTglofVOml7V5TisW8o+3Rvxv3?= =?us-ascii?Q?T5WodXa/v7yyfwRglZo51KYbuGN7+pKM3pNkmm6f?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR18MB4086.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a9c2ca9-fca3-4e4d-3ec5-08dc36970a98 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2024 06:49:12.5017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: T78C23dhVjfQ2QQQiyy20IrU+ulqwM6b/5XW3130CEa+jzoU0fyt9tphbyqUciWB/oW12zCY/W2W7diqOSsB3sLCVqbbl7dME+iaCS7i3Ug= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3461 X-Proofpoint-ORIG-GUID: SMLkTl_IE-AApqlN7_5z_qWQ5NTjh_3o X-Proofpoint-GUID: SMLkTl_IE-AApqlN7_5z_qWQ5NTjh_3o X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-26_03,2024-02-23_01,2023-05-22_02 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 > The description of ordered and atomic scheduling given in the eventdev > doxygen documentation was not always clear. Try and simplify this so > that it is clearer for the end-user of the application >=20 > Signed-off-by: Bruce Richardson > Acked-by: Pavan Nikhilesh =20 > --- > V4: reworked following review by Jerin > V3: extensive rework following feedback. Please re-review! > --- > lib/eventdev/rte_eventdev.h | 77 +++++++++++++++++++++++-------------- > 1 file changed, 48 insertions(+), 29 deletions(-) >=20 > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h > index 72814719b2..6d881bd665 100644 > --- a/lib/eventdev/rte_eventdev.h > +++ b/lib/eventdev/rte_eventdev.h > @@ -1397,25 +1397,36 @@ struct rte_event_vector { > /**< Ordered scheduling > * > * Events from an ordered flow of an event queue can be scheduled to > multiple > - * ports for concurrent processing while maintaining the original event = order. > - * This scheme enables the user to achieve high single flow throughput b= y > - * avoiding SW synchronization for ordering between ports which bound to > cores. > - * > - * The source flow ordering from an event queue is maintained when event= s > are > - * enqueued to their destination queue within the same ordered flow > context. > - * An event port holds the context until application call > - * rte_event_dequeue_burst() from the same port, which implicitly releas= es > - * the context. > - * User may allow the scheduler to release the context earlier than that > - * by invoking rte_event_enqueue_burst() with RTE_EVENT_OP_RELEASE > operation. > - * > - * Events from the source queue appear in their original order when > dequeued > - * from a destination queue. > - * Event ordering is based on the received event(s), but also other > - * (newly allocated or stored) events are ordered when enqueued within t= he > same > - * ordered context. Events not enqueued (e.g. released or stored) within= the > - * context are considered missing from reordering and are skipped at th= is > time > - * (but can be ordered again within another context). > + * ports for concurrent processing while maintaining the original event = order, > + * i.e. the order in which they were first enqueued to that queue. > + * This scheme allows events pertaining to the same, potentially large, = flow to > + * be processed in parallel on multiple cores without incurring any > + * application-level order restoration logic overhead. > + * > + * After events are dequeued from a set of ports, as those events are re= - > enqueued > + * to another queue (with the op field set to @ref > RTE_EVENT_OP_FORWARD), the event > + * device restores the original event order - including events returned = from all > + * ports in the set - before the events are placed on the destination qu= eue, > + * for subsequent scheduling to ports. > + * > + * Any events not forwarded i.e. dropped explicitly via RELEASE or impli= citly > + * released by the next dequeue operation on a port, are skipped by the > reordering > + * stage and do not affect the reordering of other returned events. > + * > + * Any NEW events sent on a port are not ordered with respect to FORWARD > events sent > + * on the same port, since they have no original event order. They also = are not > + * ordered with respect to NEW events enqueued on other ports. > + * However, NEW events to the same destination queue from the same port > are guaranteed > + * to be enqueued in the order they were submitted via > rte_event_enqueue_burst(). > + * > + * NOTE: > + * In restoring event order of forwarded events, the eventdev API > guarantees that > + * all events from the same flow (i.e. same @ref rte_event.flow_id, > + * @ref rte_event.priority and @ref rte_event.queue_id) will be put in= the > original > + * order before being forwarded to the destination queue. > + * Some eventdevs may implement stricter ordering to achieve this aim, > + * for example, restoring the order across *all* flows dequeued from t= he > same ORDERED > + * queue. > * > * @see rte_event_queue_setup(), rte_event_dequeue_burst(), > RTE_EVENT_OP_RELEASE > */ > @@ -1423,18 +1434,26 @@ struct rte_event_vector { > #define RTE_SCHED_TYPE_ATOMIC 1 > /**< Atomic scheduling > * > - * Events from an atomic flow of an event queue can be scheduled only to= a > + * Events from an atomic flow, identified by a combination of @ref > rte_event.flow_id, > + * @ref rte_event.queue_id and @ref rte_event.priority, can be scheduled > only to a > * single port at a time. The port is guaranteed to have exclusive (atom= ic) > * access to the associated flow context, which enables the user to avoi= d SW > - * synchronization. Atomic flows also help to maintain event ordering > - * since only one port at a time can process events from a flow of an > - * event queue. > - * > - * The atomic queue synchronization context is dedicated to the port unt= il > - * application call rte_event_dequeue_burst() from the same port, > - * which implicitly releases the context. User may allow the scheduler t= o > - * release the context earlier than that by invoking > rte_event_enqueue_burst() > - * with RTE_EVENT_OP_RELEASE operation. > + * synchronization. Atomic flows also maintain event ordering > + * since only one port at a time can process events from each flow of an > + * event queue, and events within a flow are not reordered within the > scheduler. > + * > + * An atomic flow is locked to a port when events from that flow are fir= st > + * scheduled to that port. That lock remains in place until the > + * application calls rte_event_dequeue_burst() from the same port, > + * which implicitly releases the lock (if @ref > RTE_EVENT_PORT_CFG_DISABLE_IMPL_REL flag is not set). > + * User may allow the scheduler to release the lock earlier than that by > invoking > + * rte_event_enqueue_burst() with RTE_EVENT_OP_RELEASE operation for > each event from that flow. > + * > + * NOTE: Where multiple events from the same queue and atomic flow are > scheduled to a port, > + * the lock for that flow is only released once the last event from the = flow is > released, > + * or forwarded to another queue. So long as there is at least one event= from > an atomic > + * flow scheduled to a port/core (including any events in the port's deq= ueue > queue, not yet read > + * by the application), that port will hold the synchronization lock for= that > flow. > * > * @see rte_event_queue_setup(), rte_event_dequeue_burst(), > RTE_EVENT_OP_RELEASE > */ > -- > 2.40.1