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-boun...@dpdk.org] On Behalf Of Jerin Jacob > > Sent: Wednesday, December 21, 2016 14:55 > > To: dev@dpdk.org > > Cc: thomas.monja...@6wind.com; bruce.richard...@intel.com; Hemant > > Agrawal <hemant.agra...@nxp.com>; gage.e...@intel.com; > > harry.van.haa...@intel.com; Jerin Jacob <jerin.ja...@caviumnetworks.com> > > 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 <jerin.ja...@caviumnetworks.com> > > Acked-by: Bruce Richardson <bruce.richard...@intel.com> > > --- > > 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 > > <snip> > > > + > > +/** > > + * 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); > > + > > <Snip> > > Regards, > Nipun
