From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0063.outbound.protection.outlook.com [104.47.0.63]) by dpdk.org (Postfix) with ESMTP id F1FA25398 for ; Fri, 7 Oct 2016 12:40:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Tg3o1qW402IsjQXC0xBAMcmdZXg8rYW2k0phhsDQLbg=; b=gO3Bht7fZL9gLe/HSInETLFwLaCQipKFKGLzfQ9fkPgsTFsU+JbKQucWdt8DiGudg6KRFDHDfARhgeUvIPp4UxnBxk7Pyh0Sq+jbfE0lWw73deU0A18CLhRUIJ6f626AhfppA89SiYiD9gpk4TzXSZipQcfKkVZO3ZvVz+3Tb28= Received: from DB5PR04MB1605.eurprd04.prod.outlook.com (10.164.38.147) by DB5PR04MB1607.eurprd04.prod.outlook.com (10.164.38.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.8; Fri, 7 Oct 2016 10:40:03 +0000 Received: from DB5PR04MB1605.eurprd04.prod.outlook.com ([10.164.38.147]) by DB5PR04MB1605.eurprd04.prod.outlook.com ([10.164.38.147]) with mapi id 15.01.0659.014; Fri, 7 Oct 2016 10:40:03 +0000 From: Hemant Agrawal To: Jerin Jacob , "Vangati, Narender" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC] libeventdev: event driven programming model framework for DPDK Thread-Index: AdIeiSak13I9OJseTpeT3ARREZ5dJAAUGlcAAGgZCJA= Date: Fri, 7 Oct 2016 10:40:03 +0000 Message-ID: References: <3B5C8B5D2B969C4CBE78502867F1AD9A0134149F@FMSMSX108.amr.corp.intel.com> <20161005072451.GA2358@localhost.localdomain> In-Reply-To: <20161005072451.GA2358@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hemant.agrawal@nxp.com; x-originating-ip: [192.88.169.1] x-ms-office365-filtering-correlation-id: 4ecaf786-e48c-4c3c-1f45-08d3ee9e4c19 x-microsoft-exchange-diagnostics: 1; DB5PR04MB1607; 6:tMNv4Z5yS/p8Qr8YzLJ/pC6skDvkpCLZNssWQhYc78nvg8FytJr+OksK/nqQa0l16ZlqVo/6/OS0Dg/fVLu1oGX8/UpE+b3FXZuwmK0OYl/x0RMvITJRBgiVUbO73WrRxr6327X/zbovfOEOif38XSo1lIhbVts3nmqi4EmgKK7ijVWoxLclGyTLnDqXRqDN2MB9v9zNVrEQDiPzyguHPnT0gmKQRy2sJlC3juTddSxnCjLYMsvQ6/WKyJ3q3y6pEE2DZVnz+tgqHXU7edRO9AL/Ud9Qpj2leBCJkZ7MB3widT5ZslXyrMSQrAEjRA9py0e4yu7lv1SdwjAujLChBZiuYtx48hWD9UyINgrARPI=; 5:P5W9gJ7SAOQgvolL4aipRO29dFzJ0t77tKh3tUiMYQsQyxkmk7lqE4TbONK9FFow1fetSOFmO7LRycAD1UOhnkPNbrmGYgKAPFXplBbfvdky+1zF/Ghe65ktlwwgH5e39D8MH7OXkEjJ2nzUi0GdjQ==; 24:AYM5L1MBIz7IHwr5iarjVxakdboTvRsY/VWd+k9EB/ergIMeaphKgByL9hBHhllaoMQFrkcDdvNZzbOX7MXCLk1/qornx4rmtNyp2Z4h0nY=; 7:hDht4FY/Y5XUGBCV6SM7CwChUVG4vBD7BqgGPyJfOcSqrR6rYLJvSPauC2+XLl0H6s5nBmelwoZ5wB2sfwZ7M1E4t8/HlFHX2QZ/a1eXJldH0gJb49zuxflpBwEPOiviACaOAXSUHBeBc+EJflPYt9YNVUwpVECv7cPmmEfSTtyVb536xW4Ta9amXZWCUPzk5EAqd+8ZF+RE2j0RR+I7heX2TtWKTtJ+7H1LbMrNw4dAs3fJWTTMw9o2UCvURVlKAo45p7OWjJf6/mkY5oOgINKpo6mEzAt5EYFlEg98Wq+UzCpkTgbulmk3lmtF+MMS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1607; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(271806183753584)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DB5PR04MB1607; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1607; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(199003)(54014002)(13464003)(24454002)(51914003)(189002)(66066001)(7846002)(81156014)(81166006)(3280700002)(11100500001)(33656002)(5001770100001)(7736002)(305945005)(97736004)(5002640100001)(189998001)(86362001)(74316002)(8936002)(87936001)(19580395003)(19580405001)(8676002)(9686002)(50986999)(68736007)(10400500002)(106356001)(105586002)(76576001)(2906002)(101416001)(102836003)(122556002)(3846002)(6116002)(5660300001)(4326007)(3660700001)(586003)(77096005)(7696004)(2900100001)(92566002)(54356999)(76176999)(2950100002)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB1607; H:DB5PR04MB1605.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2016 10:40:03.7289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1607 Subject: Re: [dpdk-dev] [RFC] libeventdev: event driven programming model framework for DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 10:40:06 -0000 Hi Jerin/Narender, Thanks for the proposal and discussions.=20 I agree with many of the comment made by Narender. Here are some addition= al comments. 1. rte_event_schedule - should support option for bulk dequeue. The size of= bulk should be a property of device, how much depth it can support. 2. The event schedule should also support the option to specify the amount = of time, it can wait. The implementation may only support global setting(de= queue_wait_ns) for wait time. They can take any non-zero wait value as to i= mplement wait. =20 3. rte_event_schedule_from_group - there should be one model. Both Push an= d Pull may not work well together. At least the simultaneous mixed config w= ill not work on NXP hardware scheduler.=20 4. Priority of queues within the scheduling group? - Please keep in mind t= hat some hardware supports intra scheduler priority and some only support i= ntra flow_queue priority within a scheduler instance. The events of same fl= ow id should have same priority. 5. w.r.t flow_queue numbers in log2, I will prefer to have absolute number.= Not all system may have large number of queues. So the design should keep = in account the system will fewer number of queues. Regards, Hemant > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob > Sent: Wednesday, October 05, 2016 12:55 PM > On Tue, Oct 04, 2016 at 09:49:52PM +0000, Vangati, Narender wrote: > > Hi Jerin, >=20 > Hi Narender, >=20 > Thanks for the comments.I agree with proposed changes; I will address the= se > comments in v2. >=20 > /Jerin >=20 >=20 > > > > > > > > Here are some comments on the libeventdev RFC. > > > > These are collated thoughts after discussions with you & others to unde= rstand > the concepts and rationale for the current proposal. > > > > > > > > 1. Concept of flow queues. This is better abstracted as flow ids and no= t as flow > queues which implies there is a queueing structure per flow. A s/w > implementation can do atomic load balancing on multiple flow ids more > efficiently than maintaining each event in a specific flow queue. > > > > > > > > 2. Scheduling group. A scheduling group is more a steam of events, so a= n event > queue might be a better abstraction. > > > > > > > > 3. An event queue should support the concept of max active atomic flows > (maximum number of active flows this queue can track at any given time) a= nd > max active ordered sequences (maximum number of outstanding events waitin= g > to be egress reordered by this queue). This allows a scheduler implementa= tion to > dimension/partition its resources among event queues. > > > > > > > > 4. An event queue should support concept of a single consumer. In an > application, a stream of events may need to be brought together to a sing= le > core for some stages of processing, e.g. for TX at the end of the pipelin= e to > avoid NIC reordering of the packets. Having a 'single consumer' event que= ue for > that stage allows the intensive scheduling logic to be short circuited an= d can > improve throughput for s/w implementations. > > > > > > > > 5. Instead of tying eventdev access to an lcore, a higher level of abst= raction > called event port is needed which is the application i/f to the eventdev.= Event > ports are connected to event queues and is the object the application use= s to > dequeue and enqueue events. There can be more than one event port per lco= re > allowing multiple lightweight threads to have their own i/f into eventdev= , if the > implementation supports it. An event port abstraction also encapsulates > dequeue depth and enqueue depth for a scheduler implementations which can > schedule multiple events at a time and output events that can be buffered= . > > > > > > > > 6. An event should support priority. Per event priority is useful for s= egregating > high priority (control messages) traffic from low priority within the sam= e flow. > This needs to be part of the event definition for implementations which s= upport > it. > > > > > > > > 7. Event port to event queue servicing priority. This allows two event = ports to > connect to the same event queue with different priorities. For implementa= tions > which support it, this allows a worker core to participate in two differe= nt > workflows with different priorities (workflow 1 needing 3.5 cores, workfl= ow 2 > needing 2.5 cores, and so on). > > > > > > > > 8. Define the workflow as schedule/dequeue/enqueue. An implementation i= s > free to define schedule as NOOP. A distributed s/w scheduler can use this= to > schedule events; also a centralized s/w scheduler can make this a NOOP on= non- > scheduler cores. > > > > > > > > 9. The schedule_from_group API does not fit the workflow. > > > > > > > > 10. The ctxt_update/ctxt_wait breaks the normal workflow. If the normal > workflow is a dequeue -> do work based on event type -> enqueue, a pin_e= vent > argument to enqueue (where the pinned event is returned through the norma= l > dequeue) allows application workflow to remain the same whether or not an > implementation supports it. > > > > > > > > 11. Burst dequeue/enqueue needed. > > > > > > > > 12. Definition of a closed/open system - where open system is memory ba= cked > and closed system eventdev has limited capacity. In such systems, it is a= lso > useful to denote per event port how many packets can be active in the sys= tem. > This can serve as a threshold for ethdev like devices so they don't overw= helm > core to core events. > > > > > > > > 13. There should be sort of device capabilities definition to address d= ifferent > implementations. > > > > > > > > > > vnr > > --- > >