From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0072.outbound.protection.outlook.com [104.47.41.72]) by dpdk.org (Postfix) with ESMTP id 070C9370 for ; Tue, 29 Nov 2016 04:43:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/ZaizVRxVYB0GYYtj+ZFlltiY6pHIBsQcY3E0KA3xcM=; b=oXj8jgkvffGHRiTindUW7evEisyosM3/b2xsIHea+duA1WBqRZkYU1PUS84IKfipThMJ7sQGtsthspxiTXDCwupSGWdErVDDmmbO7fDAvKgfwi5Y8DlvRLT+zPNUBJCZso8Jg10yDMfb7RJgXsrsluINoyoysjF/9hIVqys7cGE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from svelivela-lt.caveonetworks.com (50.233.148.156) by CY1PR0701MB1725.namprd07.prod.outlook.com (10.163.21.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Tue, 29 Nov 2016 03:43:09 +0000 Date: Tue, 29 Nov 2016 09:13:05 +0530 From: Jerin Jacob To: "Eads, Gage" CC: "dev@dpdk.org" , "Richardson, Bruce" , "Van Haaren, Harry" , "hemant.agrawal@nxp.com" Message-ID: <20161129034304.GB9930@svelivela-lt.caveonetworks.com> References: <9184057F7FC11744A2107296B6B8EB1E01E31739@FMSMSX108.amr.corp.intel.com> <20161121191358.GA9044@svelivela-lt.caveonetworks.com> <20161121193133.GA9895@svelivela-lt.caveonetworks.com> <9184057F7FC11744A2107296B6B8EB1E01E31C40@FMSMSX108.amr.corp.intel.com> <20161122181913.GA9456@svelivela-lt.caveonetworks.com> <9184057F7FC11744A2107296B6B8EB1E01E32F3E@FMSMSX108.amr.corp.intel.com> <20161122200022.GA12168@svelivela-lt.caveonetworks.com> <9184057F7FC11744A2107296B6B8EB1E01E331A3@FMSMSX108.amr.corp.intel.com> <20161122234331.GA20501@svelivela-lt.caveonetworks.com> <9184057F7FC11744A2107296B6B8EB1E01E33E96@FMSMSX108.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E01E33E96@FMSMSX108.amr.corp.intel.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Originating-IP: [50.233.148.156] X-ClientProxiedBy: DM2PR0501CA0015.namprd05.prod.outlook.com (10.162.29.153) To CY1PR0701MB1725.namprd07.prod.outlook.com (10.163.21.14) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 2:V4z8MuFVPwsdCh769ekRDYAzhDKjnh//C6S0uv7GmG0WTmWJpccboQ+NaCQyXvsKkc1LWWy8QLdOSUN/pS33PogWxItfYYhurnvXSd/OHnAxzp4LX0jwBhb6Qbqm/oUa8tB55RNC0Ex+T2Rm84wBTKz+G29ZY33poX7JyipfDd8=; 3:p9WvQexQYm/xmtQPtbheAtZhIAgsniJq1C5Cqy7JiOtSPhuYm1l2oeqbkj8XGyVojcBjObICRCz1M0Y4GQw8oor2veabUbbQrF/GRurVNUWyIsRfKFLiqYKsWJ1Dfd53SFOWrnbfuSQzoH5nvno/OFnEaO9rxF7gK5hyztXWqjQ=; 25:Alf/bIXKFHlliDayxyR8T1b7wVHkxxdmRS2AgK1bjQhqFGK3TSyPioB51sA7tCY4Hrh5ZrGNe5fX8izyVlUEQ9FL+4EFxK/xm4nLh/EopK5uIBOrj1oh+eYDz6lnX4kuIe5mctPOQUux1N/KTu+Mm4AzObTm2p8mejOV2AcXuBnhaoq+6Wu0n224HEnBCAZZrOdfx68dHZ6dXIlSOuAzs2RBhJDKmmzgjLVx6DOIVmfevN7Z4hxQjeN39bn5QxYJAcR58GWByMOj5CXtvkEoKFclqZHxpUQVmBS0MpQpf42MRo/vruQgngQhv7nXAjvQ1seplx68ockjLMBySw6/OiUlS59taJdMRu0dHpkTa2xnzRcHAX3BBaiYiWkEjihZCwz5sWvgPprphzX8VlTVTbTsRo6VBAoKADapUyEG+sBYlGuHYBemYeatr+gY3AGo1aHg9OXANW7akfVOX47qHw== X-MS-Office365-Filtering-Correlation-Id: 5d3b922a-bae5-4b51-254e-08d41809d688 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0701MB1725; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 31:cL3sHM2Mr1cKg+V/6nU6LBmMBr8kSTcx/T5m2OfzjYdnHYiGeOMfmbyrTeb6IxsBNdOyr51fomUAZ+NTH8XFNwMrzJVZrPw3w0Qz1GXWqAVZKJjvaXAZHbFIU96DvrHIrsCez8aDscWKzlsFBSV1luV31oFsZeJvUXj9sPlu8DmmHdOHWRmnVusQBSV/4ub0uFjw2NxCDSMZAjAG0vBuwfXCbu9Ju9vjXy9hJ/UepWXtYp2pZbCP+Ecwjlm7mvmr3gSBMLQyFA0wkky1xm6OuA==; 20:BXRjmMSTZVY8Y9hLUpeDV2pAFuRtpAb2KheFhxV+KatjGoOj03n7CSbMd8FxylMwspW7lKOXNALX/WV9u7Rry8Tlld8ebD4869EugaiUYNGOPWr4t81tcWUUy3j3qAiRRQt6n9zZDAw4abfAzeHg4C/+6auCXBMP0pbw9UgSZyWsymhwaNagnro8Io2ffy9Q0zsiyR8LmfnxHNlodgK9WNDQvc3bGlodACEiRlekeQRJaDWWhUuNZaHrW0s0rY6ayOsjtUVZrNEG9UlGBUS9qJWwWnQLAO0dESLrwTpxmn1JMmuA7Ox93aABysi9xGn8PGbZQn3jOcm2VVz8fSMqed4vUMVbvRRS/Uy39nB85CSW2Xa9bvN9QBvHaq2DKPsLH9ZATx8GvkdcVD8stgV+b7ec1ch3sLWO1V5UbcMl22sbTLQfzCHbV4artVx9wbcqX0lRlHcMjRF8Ka8EI290pvXFPH7fYP8k6qPDh/Lf7tiI3UrIf6MXKFHNXey3Ve6+N8srQalQkWOHAF0gjQoA/tXBw1QgW246dSnHyvN30NJxPZzLnxRrU6hK5Tl98Jd1uLNivUXLvF4Dw6wp3WYvG5uJuAtmlUbFQmGsewDc58w= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(271806183753584)(185117386973197)(228905959029699)(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6045199)(6060326)(6040361)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(6061324)(20161123558021)(20161123560025)(20161123555025)(20161123562025)(20161123564025); SRVR:CY1PR0701MB1725; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1725; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 4:eBkCNqAhgNNLI/5lv3FyYZQH3vTzWXvUeghIrxzRhVTfYOq6QqiibCIjb36Qv1BzP1S4Cs71AGyV7WISqm19ONZ8vpBt1F73E/eON3fYzAM5EWMCB0farR0JI7IwUI0MVtbti/XoY+oETt534iXQDFXIhA7KTudLjXDUV5qMFvGKhjfHWO+LnchtQMhs0tePffYSohKjVXfjsYtIMHspyTZl246XcFOlomE1oREhhSSQlF7cM923fk1NIROCSL6XcLcAsAvyiX2XNNwkWWKI5RqIoQbs6dx6aCVDDAXrCqRl/trJjzOvKoi1EgP9/4k1KQERZ6ZsnNXW+/ejPUuPwa0ls1DYk+MKLrhsDMsbRWtWi2QGomr5I6Bu2YZ5TXGJozGcbl4m3C47f/jdsskcRUYxshO0agqe7r7nFZVMIU8JbCoHOhnTSNxeD+SE4mOTej0QW8eTmd8ddmWuCrwnqaOuHn/0ArXtIQG3DQylys1IjhVkUNzKQO9vDm5SMjcp2vdor4RoRYekWEU5RYtRpSvKLhdc8A8rBI0Tc0jNfY0129jN/D8qjkk03+v4wmCgPI4UKZsd/IXUMShRuauNfEzao4oblY8dmGYhFNxuCPP3yNlXy1vi8Bsc2ok4PntutOktTBeOUXL3/XasS2bY88iRxIE0UuVUsbB7pF21AR/vBOF6JJ/N+O5+OQD33rEhmStIVQZ5ddRHez++d7nifR1yj1FaGQcoMZ8O4aPvrhs0qegoCOiTCudd2Gdt4jczJPEjQ5Pi47YNzMKAcc68QxHyoj0B6EO94B7WQ4iBgfZeD7q7e4NCZujcuehr/XFUpxNHg9yOztlE1MY1ALpaLg== X-Forefront-PRVS: 01415BB535 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(13464003)(377454003)(24454002)(189002)(76094002)(199003)(7846002)(39410400001)(7736002)(81156014)(305945005)(105586002)(39380400001)(110136003)(3846002)(68736007)(5660300001)(6666003)(54356999)(46406003)(92566002)(561944003)(50986999)(97756001)(2950100002)(76176999)(101416001)(9686002)(93886004)(6916009)(42882006)(106356001)(8666005)(8676002)(189998001)(97736004)(47776003)(42186005)(39400400001)(33656002)(6116002)(23726003)(50466002)(69596002)(4001350100001)(1076002)(38730400001)(2906002)(83506001)(66066001)(53416004)(4326007)(733004)(81166006)(39450400002)(229853002)(18370500001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1725; H:svelivela-lt.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0701MB1725; 23:sfQdqVqjTjhUgOZ60iWVFyAaNoeVvC925Dt8dhT?= =?us-ascii?Q?D4hS+3tQGczYOJUt74u4mqt6z/rpIM3LMH4PFANRPneUW21nIPEp1YxUcyD+?= =?us-ascii?Q?HfUWVEZiL2EbglV4OKccL3mjveZZhIcGceDzSxZrMbXicIm8oZmMAEMki60l?= =?us-ascii?Q?kNMZmIGNBnxjAAVnplCjkcY9bRTgRHs6BJWYKdjznmiD28tLlvKlUWL21FMD?= =?us-ascii?Q?Ml4vyOUrDztUMKrPxhSQv332oX15aw6ryFs/o3mdSLWulAB3qJ11qt6o+/NM?= =?us-ascii?Q?vhcyPgXrmDvTUdqrL5SLn8n+5mVKTYhtBhUV09EEWkbTWWurcEz6NwunZT9F?= =?us-ascii?Q?4w7KSIdUd48bXOs5RqHKl2iYGUD895AVPFvIfWBmcm6KZJhrXCqcuyI9Qte6?= =?us-ascii?Q?blDgf80/kFQQM9LF06sDnz8EOIlzJyoyCqrpdDNvMyIskTAnU46ArxAsopN0?= =?us-ascii?Q?uZJKUqKJxloQVmcq3vBSKFZK5poGOmj/pEWPhVu1Qe4uxEYJln9ESujtRUZD?= =?us-ascii?Q?w+rh6uZ2M5McDdsWiv7on2S9BClVYOkDbMRTYXBfXMzkmSk2+10nNGPBdAQy?= =?us-ascii?Q?5tvf/X4sil3OoQ7Pl33L43g8fmMTkm+9/hJ87khMR7A5hlcQp16TrV+1HiqC?= =?us-ascii?Q?nvpFiUbZUrUg/5nRzZER56daUKEIu8rtZnzhvQ573mCJWYny6fOUiOUOO2mE?= =?us-ascii?Q?2p6tX0QcE7Yg7QuLaKF+Uu1jDC3CAEDIBQ5JVJz1+p6kOiOqbov+BjCLORLq?= =?us-ascii?Q?tQvNrkfUsOsCL1khM3+ixM+UkEaODu9T0pOFpqPoSVmW3jTFOJuGx1dEocDW?= =?us-ascii?Q?CwyUiP+xW4aB51kwCzR2AH88SGRyldKe7HKdA1CgMfOIgrd3BKt1/z+nQqvx?= =?us-ascii?Q?92d2/GtGSDD2lHJjO5XEV386T1e/pYGB3s1KiyYCA1WX3wW0dN4Q8E0ZGHrX?= =?us-ascii?Q?P3WiEjs9WV6baWub/XXEkvlwwSYqVNbZfLYETq8bz4JhXgwj4z8lb3XynuXQ?= =?us-ascii?Q?7tagB0+eDsBF6awZXHfk5RlRUot/7dlxKicj/jaZHnriDBARhi5R97X8S4EG?= =?us-ascii?Q?Lu1NmG34U7Wh833jCbhTi5/y4NWUIsv8ZNKP2oAi8+Znpiz6hJodjHJqoyEk?= =?us-ascii?Q?JmW0lC16BV2glklEY36pXrJLa7FY5xW+5QiCEVS6ei1lLVWn3TbScWIIO9kO?= =?us-ascii?Q?c+Bvftsqr3/bLsMUOXNA7SuP87Trspl4Xhvs8VoHdJ7uEVyiPV2Lz2ZVgCZV?= =?us-ascii?Q?bnKHv4M8syoKD8JnmkZ8gds8dOdc0b+1FXtvwEWoEd2O+yhrrQg60XKjLjp9?= =?us-ascii?Q?MuMup1XzLTuLm0dJd/VLFzYJZG+GBN585Ys4JUaeXgJUR8uN08FxDJBAvLhQ?= =?us-ascii?Q?5lI7EMyeD3FdPdlRxoFshv7bErn2ZcFG/icLEsEwxJ6VPtTHuCA3My/mfj3W?= =?us-ascii?Q?3E1C4uYxjQ2I3ZUoXHbX+TFDDZqJ5BHMrVMUrdL9AfHBGPyR/d4qQWBxAUbM?= =?us-ascii?Q?gEr+AkpbJj5nhmA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 6:lMtXIhHn8FNbuRZbVGyuB2GdwanpihPGn7epQPRbaNaENdFgeHuWIqbRFjRNmd9/JkCv6iXwOhUldnK+oxfsG/BZJR85cKrJJIlNoAKKUhNpkCqw5bPi/AxzDasPo8qTvjrVScWicuBTvnSKVztVZoVAtlGChv4KLXLySpWXBqM7BPXiY6bjiV40/TGQb+spUXHvba4o24Mqt8duh3OM94uaCwY15mGi/dj5uAVHBfzv3ruDaeQhZlRbJ5zNmEDwwookCJCQl0h6GNH0Yb0gaddFI44fBGC9qp1j3j88aP9sk/4I1UkoGT9/TqyhV0VnC7aE1K2KzBi6yQzwaI+4+kIR0EVIEMhIqFYnnMIdHk8=; 5:ypQilL/IlTSScTOx9/+vGSngR+yC1S/1l8dlNByCjkjg3d7+eRa4fj2HmzIAtClg/9k79pQoYZ0NnQhIlhgISuJ7JtsugzGd5qtAv4tlv0NVq3N3ey0oOrSvXXCYP1x2yWPyR+LMNXFAGQpjfmnnGQ==; 24:/WOVrl2AR7Gp0DKmAD0O2XjA0T4fRfae4k+09b7tLWBih1hskFxQgyhkO4UhDOFqSLqUcxgO0ddOv3T3DhHhC9wj3BAaZAOMmkzez3PjMIQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1725; 7:5iAoLQ2HcJm6xfunpyBHJSP7svb53LOM/oMQvHyjTxqddA4KrvUaKDbdMZiXRDMVIQKwAuM0nHe1IiQTSTz1ZASSYCYVWhbgx/OBh/GURvcCr7LovRItR7UtrzYGdziTb/VOlNMLXE4uLixU2ooEq9oQdaRMej57UWX07/l8Pw52UdNxeGTHQ7X6ArDLNbKbYalZ//a3XeMvdUi5Er6p4P+AZ2nHRmiqAf6vrcUVrTmHeyZL1U9pNOH7NWo9Z7ewl/OLDsIeJe7xVeangRwQC0NY7pvDFRxdCFA2NY0cPJENPziv9f0shdA31SBDBsx3SSSKm4H/qANXPVf8guVICtfRRfWO+hFoilOGJwl4PAE= X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2016 03:43:09.4101 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1725 Subject: Re: [dpdk-dev] [PATCH 2/4] eventdev: implement the northbound APIs 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: Tue, 29 Nov 2016 03:43:14 -0000 On Mon, Nov 28, 2016 at 03:53:08PM +0000, Eads, Gage wrote: > (Bruce's adviced heeded :)) > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Tuesday, November 22, 2016 5:44 PM > > To: Eads, Gage > > Cc: dev@dpdk.org; Richardson, Bruce ; Van > > Haaren, Harry ; hemant.agrawal@nxp.com > > Subject: Re: [dpdk-dev] [PATCH 2/4] eventdev: implement the northbound APIs > > > > On Tue, Nov 22, 2016 at 10:48:32PM +0000, Eads, Gage wrote: > > > > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > Sent: Tuesday, November 22, 2016 2:00 PM > > > > To: Eads, Gage > > > > Cc: dev@dpdk.org; Richardson, Bruce ; > > > > Van Haaren, Harry ; > > > > hemant.agrawal@nxp.com > > > > Subject: Re: [dpdk-dev] [PATCH 2/4] eventdev: implement the > > > > northbound APIs > > > > > > > > On Tue, Nov 22, 2016 at 07:43:03PM +0000, Eads, Gage wrote: > > > > > > > > > > One open issue I noticed is the "typical workflow" > > > > > > description starting in > > rte_eventdev.h:204 conflicts with > > > > the > > centralized software PMD that Harry > > posted last week. > > > > > > Specifically, that PMD expects a single core to call the > > > > > > > > schedule function. We could extend the documentation to account > > > > for > > this > > alternative style of scheduler invocation, or > > > > discuss > > ways to make the software > > PMD work with the > > > > documented > > workflow. I prefer the former, but either way I > > > > > > think we > > ought to expose the scheduler's expected usage to > > > > the user -- > > perhaps > > through an RTE_EVENT_DEV_CAP flag? > > > > > > > > > > > > > > > > > > I prefer former too, you can propose the documentation > > > > > > change required for > > software PMD. > > > > > > > > > > > > > > Sure, proposal follows. The "typical workflow" isn't the > > > > most > > optimal by having a conditional in the fast-path, of > > > > course, but it > > demonstrates the idea simply. > > > > > > > > > > > > > > (line 204) > > > > > > > * An event driven based application has following typical > > > > > > workflow on > > fastpath: > > > > > > > * \code{.c} > > > > > > > * while (1) { > > > > > > > * > > > > > > > * if (dev_info.event_dev_cap & > > > > > > > * RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED) > > > > > > > * rte_event_schedule(dev_id); > > > > > > > > > > > > Yes, I like the idea of RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED. > > > > > > It can be input to application/subsystem to launch separate > > > > > > core(s) for schedule functions. > > > > > > But, I think, the "dev_info.event_dev_cap & > > > > > > RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED" > > > > > > check can be moved inside the implementation(to make the > > > > better > > decisions and avoiding consuming cycles on HW based > > schedulers. > > > > > > > > > > How would this check work? Wouldn't it prevent any core from > > > > running the software scheduler in the centralized case? > > > > > > > > I guess you may not need RTE_EVENT_DEV_CAP here, instead need flag > > > > for device configure here > > > > > > > > #define RTE_EVENT_DEV_CFG_DISTRIBUTED_SCHED (1ULL << 1) > > > > > > > > struct rte_event_dev_config config; config.event_dev_cfg = > > > > RTE_EVENT_DEV_CFG_DISTRIBUTED_SCHED; > > > > rte_event_dev_configure(.., &config); > > > > > > > > on the driver side on configure, > > > > if (config.event_dev_cfg & RTE_EVENT_DEV_CFG_DISTRIBUTED_SCHED) > > > > eventdev->schedule = NULL; > > > > else // centralized case > > > > eventdev->schedule = your_centrized_schedule_function; > > > > > > > > Does that work? > > > > > > Hm, I fear the API would give users the impression that they can select the > > scheduling behavior of a given eventdev, when a software scheduler is more > > likely to be either distributed or centralized -- not both. > > > > Even if it is capability flag then also it is per "device". Right ? > > capability flag is more of read only too. Am i missing something here? > > > > Correct, the capability flag I'm envisioning is per-device and read-only. > > > > > > > What if we use the capability flag, and define rte_event_schedule() as the > > scheduling function for centralized schedulers and rte_event_dequeue() as the > > scheduling function for distributed schedulers? That way, the datapath could be > > the simple dequeue -> process -> enqueue. Applications would check the > > capability flag at configuration time to decide whether or not to launch an > > lcore that calls rte_event_schedule(). > > > > I am all for simple "dequeue -> process -> enqueue". > > rte_event_schedule() added for SW scheduler only, now it may not make sense > > to add one more check on top of "rte_event_schedule()" to see it is really need > > or not in fastpath? > > > > Yes, the additional check shouldn't be needed. In terms of the 'typical workflow' description, this is what I have in mind: > > * > * An event driven based application has following typical workflow on fastpath: > * \code{.c} > * while (1) { > * > * rte_event_dequeue(...); > * > * (event processing) > * > * rte_event_enqueue(...); > * } > * \endcode > * > * The events are injected to event device through the *enqueue* operation by > * event producers in the system. The typical event producers are ethdev > * subsystem for generating packet events, core(SW) for generating events based > * on different stages of application processing, cryptodev for generating > * crypto work completion notification etc > * > * The *dequeue* operation gets one or more events from the event ports. > * The application process the events and send to downstream event queue through > * rte_event_enqueue() if it is an intermediate stage of event processing, on > * the final stage, the application may send to different subsystem like ethdev > * to send the packet/event on the wire using ethdev rte_eth_tx_burst() API. > * > * The point at which events are scheduled to ports depends on the device. For > * hardware devices, scheduling occurs asynchronously. Software schedulers can > * either be distributed (each worker thread schedules events to its own port) > * or centralized (a dedicated thread schedules to all ports). Distributed > * software schedulers perform the scheduling in rte_event_dequeue(), whereas > * centralized scheduler logic is located in rte_event_schedule(). The > * RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED capability flag indicates whether a > * device is centralized and thus needs a dedicated scheduling thread that Since we are starting a dedicated thread in centralized case, How about name the flag as RTE_EVENT_DEV_CAP_CENTRALIZED_SCHED? instead of RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED. No strong opinion here. Just a thought. > * repeatedly calls rte_event_schedule(). > * > */