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, 15 Dec 2016 19:09:45 +0530 Message-ID: <20161215133944.GA31972@localhost.localdomain> 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> <20161214151922.GB110884@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 NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0055.outbound.protection.outlook.com [104.47.41.55]) by dpdk.org (Postfix) with ESMTP id E20E22BFF for ; Thu, 15 Dec 2016 14:40:07 +0100 (CET) Content-Disposition: inline In-Reply-To: <20161214151922.GB110884@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 14, 2016 at 03:19:22PM +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 > > --- > > > + * > > + * The *nb_events* parameter is the number of event objects to enqueue which are > > + * supplied in the *ev* array of *rte_event* structure. > > + * > > + * The rte_event_enqueue_burst() function returns the number of > > + * events objects it actually enqueued. A return value equal to *nb_events* > > + * means that all event objects have been enqueued. > > + * > > + * @param dev_id > > + * The identifier of the device. > > + * @param port_id > > + * The identifier of the event port. > > + * @param ev > > + * Points to an array of *nb_events* objects of type *rte_event* structure > > + * which contain the event object enqueue operations to be processed. > > + * @param nb_events > > + * The number of event objects to enqueue, typically number of > > + * rte_event_port_enqueue_depth() available for this port. > > + * > > + * @return > > + * The number of event objects actually enqueued on the event device. The > > + * return value can be less than the value of the *nb_events* parameter when > > + * the event devices queue is full or if invalid parameters are specified in a > > + * *rte_event*. If return value is less than *nb_events*, the remaining events > > + * at the end of ev[] are not consumed,and the caller has to take care of them > > + * > > + * @see rte_event_port_enqueue_depth() > > + */ > > +uint16_t > > +rte_event_enqueue_burst(uint8_t dev_id, uint8_t port_id, struct rte_event ev[], > > + uint16_t nb_events); > > + > One suggestion - do we want to make the ev[] array const, to disallow > drivers from modifying the events passed in? Since the event structure > is only 16B big, it should be small enough to be copied around in > scheduler instances, allow the original events to remain unmodified. Seems like a good idea to me. I will add it in v3. > > /Bruce