From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30081.outbound.protection.outlook.com [40.107.3.81]) by dpdk.org (Postfix) with ESMTP id A75AF2BCD for ; Fri, 3 Feb 2017 07:38:49 +0100 (CET) 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=MrqwdnNGnxfAMBSSsW0SvqHpcz/cbGakg6pqy7VeAMA=; b=bucIZob3xtgEUxkx1Il94YKVwR1xpdVuJxDA2J0EmEMIjTPcqALS5ii4L/VggRH9N4BG6+M3zMnlZHj5Kla+65SHDqpP8yINcPTXYXzJvgol4pariwmFQOW65+fwPdvcrBqoBRcM/BTCq2MLkAAAeOoIw2s0oEtUHdVfVla/fCI= Received: from AM5PR0401MB2514.eurprd04.prod.outlook.com (10.169.244.146) by DB5PR04MB1605.eurprd04.prod.outlook.com (10.164.38.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Fri, 3 Feb 2017 06:38:48 +0000 Received: from AM5PR0401MB2514.eurprd04.prod.outlook.com ([10.169.244.146]) by AM5PR0401MB2514.eurprd04.prod.outlook.com ([10.169.244.146]) with mapi id 15.01.0874.021; Fri, 3 Feb 2017 06:38:47 +0000 From: Nipun Gupta To: Jerin Jacob , "bruce.richardson@intel.com" , "gage.eads@intel.com" CC: "dev@dpdk.org" , "thomas.monjalon@6wind.com" , Hemant Agrawal , "harry.van.haaren@intel.com" Thread-Topic: [dpdk-dev] [PATCH v4 1/6] eventdev: introduce event driven programming model Thread-Index: AQHSfV36OWIazUpdY02BkJYRxKJ/o6FWsMFg Date: Fri, 3 Feb 2017 06:38:47 +0000 Message-ID: References: <1480996340-29871-1-git-send-email-jerin.jacob@caviumnetworks.com> <1482312326-2589-1-git-send-email-jerin.jacob@caviumnetworks.com> <1482312326-2589-2-git-send-email-jerin.jacob@caviumnetworks.com> <20170202140911.GA26986@localhost.localdomain> In-Reply-To: <20170202140911.GA26986@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=nipun.gupta@nxp.com; x-originating-ip: [192.88.169.1] x-microsoft-exchange-diagnostics: 1; DB5PR04MB1605; 7:CodAnNNKVjZGCsY8U39jcF+S7IlXyji0QeXcLFdQuCMEDt0VR8waBK+moKuPi8R/RCguCqcCAD55jyRA1J6Dgl3Nh5RRKYxhJmBKf5TR4GJzyenM9lr5shPt7WWfOIgs1fxVG14Ta+SDKlEo/x0GUkl8kMXGFf28GRAxQpnesVLT78kWtaaxo4YvPWMlbLz9jJ9WOpIKu8PaHZ/135wkpyt2a4NwyBFvNK7kGSCn4Wwd+zaUOq9kQZclgMAA6Dt3Q7LmbeDCs57sYYysFim92kgNTuQWdlicfS64whRf7RQg6qDncw21uaibJnz2wDle4Py9GzIABl8+fBbRTB/atvk+tRKLmVlHDl3DEFCFAoxaN/mTRhc4XXRnlgVaMVWto85ExHIp6GP4UPo0TqLdyN5QyFNr+qtrqjRQZTUSQ2F0fuhNYxJvE+Yb4tukhtKSaHDJsZ5JlKJzgowE5KCaDPvarkHiLR6vG/c/sm1et2PblqflPv/lATC34UWCscTJAY/d3doD+j3zYnrvacoamw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(24454002)(13464003)(199003)(189002)(2900100001)(25786008)(77096006)(54906002)(50986999)(76176999)(54356999)(6436002)(68736007)(101416001)(38730400001)(189998001)(6506006)(33656002)(229853002)(99286003)(66066001)(55016002)(5660300001)(53936002)(74316002)(305945005)(7736002)(5001770100001)(97736004)(7696004)(8676002)(3846002)(92566002)(102836003)(6116002)(2950100002)(9686003)(81166006)(81156014)(122556002)(106356001)(2501003)(3660700001)(2906002)(106116001)(105586002)(4326007)(8936002)(86362001)(2201001)(6246003)(93886004)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB1605; H:AM5PR0401MB2514.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: bb0e97d5-7df3-44e5-a1cc-08d44bff4eb9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DB5PR04MB1605; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(185117386973197)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(20161123555025)(6072148); SRVR:DB5PR04MB1605; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1605; x-forefront-prvs: 02070414A1 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: 03 Feb 2017 06:38:47.3663 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1605 Subject: Re: [dpdk-dev] [PATCH v4 1/6] eventdev: introduce event driven programming model X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 06:38:49 -0000 > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Thursday, February 02, 2017 19:39 > To: Nipun Gupta > Cc: dev@dpdk.org; thomas.monjalon@6wind.com; > bruce.richardson@intel.com; Hemant Agrawal ; > gage.eads@intel.com; harry.van.haaren@intel.com > Subject: Re: [dpdk-dev] [PATCH v4 1/6] eventdev: introduce event driven > programming model >=20 > On Thu, Feb 02, 2017 at 11:18:52AM +0000, Nipun Gupta wrote: > > Hi, > > > > I had a few queries/comments regarding the eventdev patches. > > > > Please see inline. > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob > > > Sent: Wednesday, December 21, 2016 14:55 > > > To: dev@dpdk.org > > > Cc: thomas.monjalon@6wind.com; bruce.richardson@intel.com; Hemant > > > Agrawal ; gage.eads@intel.com; > > > harry.van.haaren@intel.com; Jerin Jacob > > > > Subject: [dpdk-dev] [PATCH v4 1/6] eventdev: introduce event driven > > > programming model > > > > > > In a polling model, lcores poll ethdev ports and associated > > > rx queues directly to look for packet. In an event driven model, > > > by contrast, lcores call the scheduler that selects packets for > > > them based on programmer-specified criteria. Eventdev library > > > adds support for event driven programming model, which offer > > > applications automatic multicore scaling, dynamic load balancing, > > > pipelining, packet ingress order maintenance and > > > synchronization services to simplify application packet processing. > > > > > > By introducing event driven programming model, DPDK can support > > > both polling and event driven programming models for packet processin= g, > > > and applications are free to choose whatever model > > > (or combination of the two) that best suits their needs. > > > > > > This patch adds the eventdev specification header file. > > > > > > Signed-off-by: Jerin Jacob > > > Acked-by: Bruce Richardson > > > --- > > > MAINTAINERS | 3 + > > > doc/api/doxy-api-index.md | 1 + > > > doc/api/doxy-api.conf | 1 + > > > lib/librte_eventdev/rte_eventdev.h | 1275 > > > ++++++++++++++++++++++++++++++++++++ > > > 4 files changed, 1280 insertions(+) > > > create mode 100644 lib/librte_eventdev/rte_eventdev.h > > > > > > > > > + > > > +/** > > > + * Event device information > > > + */ > > > +struct rte_event_dev_info { > > > + const char *driver_name; /**< Event driver name */ > > > + struct rte_pci_device *pci_dev; /**< PCI information */ > > > > With 'rte_device' in place (rte_dev.h), should we not have 'rte_device'= instead > of 'rte_pci_device' here? >=20 > Yes. Please post a patch to fix this. As the time of merging to > next-eventdev tree it was not the case. Sure. I'll send a patch regarding this. >=20 > > > > > + * The number of events dequeued is the number of scheduler contexts= held > by > > > + * this port. These contexts are automatically released in the next > > > + * rte_event_dequeue_burst() invocation, or invoking > > > rte_event_enqueue_burst() > > > + * with RTE_EVENT_OP_RELEASE operation can be used to release the > > > + * contexts early. > > > + * > > > + * @param dev_id > > > + * The identifier of the device. > > > + * @param port_id > > > + * The identifier of the event port. > > > + * @param[out] ev > > > + * Points to an array of *nb_events* objects of type *rte_event* s= tructure > > > + * for output to be populated with the dequeued event objects. > > > + * @param nb_events > > > + * The maximum number of event objects to dequeue, typically numbe= r of > > > + * rte_event_port_dequeue_depth() available for this port. > > > + * > > > + * @param timeout_ticks > > > + * - 0 no-wait, returns immediately if there is no event. > > > + * - >0 wait for the event, if the device is configured with > > > + * RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT then this function will > > > wait until > > > + * the event available or *timeout_ticks* time. > > > > Just for understanding - Is expectation that rte_event_dequeue_burst() = will > wait till timeout > > unless requested number of events (nb_events) are not received on the e= vent > port? >=20 > Yes. If you need any change then a send RFC patch for the header file > change. >=20 > > > > > + * if the device is not configured with > > > RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT > > > + * then this function will wait until the event available or > > > + * *dequeue_timeout_ns* ns which was previously supplied to > > > + * rte_event_dev_configure() > > > + * > > > + * @return > > > + * The number of event objects actually dequeued from the port. The = return > > > + * value can be less than the value of the *nb_events* parameter whe= n the > > > + * event port's queue is not full. > > > + * > > > + * @see rte_event_port_dequeue_depth() > > > + */ > > > +uint16_t > > > +rte_event_dequeue_burst(uint8_t dev_id, uint8_t port_id, struct rte_= event > > > ev[], > > > + uint16_t nb_events, uint64_t timeout_ticks); > > > + > > > > > > > > Regards, > > Nipun