From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v2 1/6] eventdev: introduce event driven programming model Date: Thu, 8 Dec 2016 07:18:01 +0530 Message-ID: <20161208014800.GB22031@svelivela-lt.caveonetworks.com> References: <1479447902-3700-2-git-send-email-jerin.jacob@caviumnetworks.com> <1480996340-29871-1-git-send-email-jerin.jacob@caviumnetworks.com> <1480996340-29871-2-git-send-email-jerin.jacob@caviumnetworks.com> <20161207111251.GA22932@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: , , , , To: Bruce Richardson Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0067.outbound.protection.outlook.com [104.47.38.67]) by dpdk.org (Postfix) with ESMTP id BCA032A66 for ; Thu, 8 Dec 2016 02:48:08 +0100 (CET) Content-Disposition: inline In-Reply-To: <20161207111251.GA22932@bricha3-MOBL3.ger.corp.intel.com> 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 Wed, Dec 07, 2016 at 11:12:51AM +0000, Bruce Richardson wrote: > On Tue, Dec 06, 2016 at 09:22:15AM +0530, Jerin Jacob wrote: > > 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 > > --- > > + > > +/** > > + * Link multiple source event queues supplied in *rte_event_queue_link* > > + * structure as *queue_id* to the destination event port designated by its > > + * *port_id* on the event device designated by its *dev_id*. > > + * > > + * The link establishment shall enable the event port *port_id* from > > + * receiving events from the specified event queue *queue_id* > > + * > > + * An event queue may link to one or more event ports. > > + * The number of links can be established from an event queue to event port is > > + * implementation defined. > > + * > > + * Event queue(s) to event port link establishment can be changed at runtime > > + * without re-configuring the device to support scaling and to reduce the > > + * latency of critical work by establishing the link with more event ports > > + * at runtime. > > + * > > + * @param dev_id > > + * The identifier of the device. > > + * > > + * @param port_id > > + * Event port identifier to select the destination port to link. > > + * > > + * @param link > > + * Points to an array of *nb_links* objects of type *rte_event_queue_link* > > + * structure which contain the event queue to event port link establishment > > + * attributes. > > + * NULL value is allowed, in which case this function links all the configured > > + * event queues *nb_event_queues* which previously supplied to > > + * rte_event_dev_configure() to the event port *port_id* with normal servicing > > + * priority(RTE_EVENT_DEV_PRIORITY_NORMAL). > > + * > > + * @param nb_links > > + * The number of links to establish > > + * > > + * @return > > + * The number of links actually established. The return value can be less than > > + * the value of the *nb_links* parameter when the implementation has the > > + * limitation on specific queue to port link establishment or if invalid > > + * parameters are specified in a *rte_event_queue_link*. > > + * If the return value is less than *nb_links*, the remaining links at the end > > + * of link[] are not established, and the caller has to take care of them. > > + * If return value is less than *nb_links* then implementation shall update the > > + * rte_errno accordingly, Possible rte_errno values are > > + * (-EDQUOT) Quota exceeded(Application tried to link the queue configured with > > + * RTE_EVENT_QUEUE_CFG_FLAG_SINGLE_LINK to more than one event ports) > > + * (-EINVAL) Invalid parameter > > + * > > + */ > > +int > > +rte_event_port_link(uint8_t dev_id, uint8_t port_id, > > + const struct rte_event_queue_link link[], > > + uint16_t nb_links); > > + > > Hi again Jerin, > > another small suggestion here. I'm not a big fan of using small > structures to pass parameters into functions, especially when not all > fields are always going to be used. Rather than use the event queue link > structure, can we just pass in two array parameters here - the list of > QIDs, and the list of priorities. In cases where the eventdev > implementation does not support link prioritization, or where the app > does not want different priority mappings , then the second > array can be null [implying NORMAL priority for the don't care case]. > > int > rte_event_port_link(uint8_t dev_id, uint8_t port_id, > const uint8_t queues[], const uint8_t priorities[], > uint16_t nb_queues); > > This just makes mapping an array of queues easier, as we can just pass > an array of ints directly in, and it especially makes it easier to > create a single link via: > > rte_event_port_link(dev_id, port_id, &queue_id, NULL, 1); The reason why I thought of creating "struct rte_event_queue_link", - Its easy to add new parameter in link attributes if required - Its _easy_ to implement PAUSE and RESUME in application PAUSE: nr_links = rte_event_port_links_get(,,link) rte_event_port_unlink_all RESUME: rte_event_port_link(,,link, nr_links); No strong opinion here. I will go with your proposal then > > Regards, > /Bruce