From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <Jerin.Jacob@cavium.com>
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 <dev@dpdk.org>; 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 <jerin.jacob@caviumnetworks.com>
To: "Eads, Gage" <gage.eads@intel.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, "Richardson, Bruce"
<bruce.richardson@intel.com>, "Van Haaren, Harry"
<harry.van.haaren@intel.com>, "hemant.agrawal@nxp.com"
<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: <CY1PR0701MB1725B383DC12B2365B85B265818D0@CY1PR0701MB1725.namprd07.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <gage.eads@intel.com>
> > Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>; Van
> > Haaren, Harry <harry.van.haaren@intel.com>; 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 <gage.eads@intel.com>
> > > > Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>;
> > > > Van Haaren, Harry <harry.van.haaren@intel.com>;
> > > > 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().
> *
> */