From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 3AAAD3DC for ; Thu, 8 Dec 2016 10:58:05 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP; 08 Dec 2016 01:57:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,318,1477983600"; d="scan'208";a="38187630" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by orsmga004.jf.intel.com with SMTP; 08 Dec 2016 01:57:53 -0800 Received: by (sSMTP sendmail emulation); Thu, 08 Dec 2016 09:57:52 +0000 Date: Thu, 8 Dec 2016 09:57:52 +0000 From: Bruce Richardson To: Jerin Jacob Cc: dev@dpdk.org, thomas.monjalon@6wind.com, hemant.agrawal@nxp.com, gage.eads@intel.com, harry.van.haaren@intel.com Message-ID: <20161208095752.GB55440@bricha3-MOBL3.ger.corp.intel.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> <20161208014800.GB22031@svelivela-lt.caveonetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161208014800.GB22031@svelivela-lt.caveonetworks.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [PATCH v2 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: Thu, 08 Dec 2016 09:58:05 -0000 On Thu, Dec 08, 2016 at 07:18:01AM +0530, Jerin Jacob wrote: > 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 Make the priority value be in a struct, perhaps. That would allow for future expansion, while still making it easier for the case where people just want the mappings without any prioritization. > - 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); Ok, I had missed that implication. Since that is probably an important operation we might want to do, perhaps links_get API should be updated too to keep parameter matching. /Bruce