From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v4 1/6] eventdev: introduce event driven programming model Date: Thu, 2 Feb 2017 19:39:12 +0530 Message-ID: <20170202140911.GA26986@localhost.localdomain> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "dev@dpdk.org" , "thomas.monjalon@6wind.com" , "bruce.richardson@intel.com" , Hemant Agrawal , "gage.eads@intel.com" , "harry.van.haaren@intel.com" To: Nipun Gupta Return-path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0064.outbound.protection.outlook.com [104.47.40.64]) by dpdk.org (Postfix) with ESMTP id 1785B9E3 for ; Thu, 2 Feb 2017 15:09:30 +0100 (CET) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 processing, > > 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? Yes. Please post a patch to fix this. As the time of merging to next-eventdev tree it was not the case. > > > + * 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* structure > > + * for output to be populated with the dequeued event objects. > > + * @param nb_events > > + * The maximum number of event objects to dequeue, typically number 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 event port? Yes. If you need any change then a send RFC patch for the header file change. > > > + * 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 when 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