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.

quoted

-----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 [off-list ref]; gage.eads@intel.com;
harry.van.haaren@intel.com; Jerin Jacob [off-list ref]	
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 <redacted>
Acked-by: Bruce Richardson <redacted>
---
 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>

quoted

+
+/**
+ * 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.

quoted

+ * 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.

quoted

+ *   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