From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id C23F737AC for ; Tue, 9 Aug 2016 10:48:50 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 09 Aug 2016 01:48:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,494,1464678000"; d="scan'208";a="1032289657" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.28]) by orsmga002.jf.intel.com with SMTP; 09 Aug 2016 01:48:48 -0700 Received: by (sSMTP sendmail emulation); Tue, 09 Aug 2016 09:48:46 +0025 Date: Tue, 9 Aug 2016 09:48:46 +0100 From: Bruce Richardson To: Jerin Jacob Cc: dev@dpdk.org, thomas.monjalon@6wind.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com Message-ID: <20160809084846.GB72228@bricha3-MOBL3> References: <20160809010138.GA8143@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160809010138.GA8143@localhost.localdomain> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [RFC] libeventdev: event driven programming model framework for DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 08:48:51 -0000 On Tue, Aug 09, 2016 at 06:31:41AM +0530, Jerin Jacob wrote: > Hi All, > > Find below an RFC API specification which attempts to > define the standard application programming interface > for event driven programming in DPDK and to abstract HW based event devices. > > These devices can support event scheduling and flow ordering > in HW and typically found in NW SoCs as an integrated device or > as PCI EP device. > > The RFC APIs are inspired from existing ethernet and crypto devices. > Following are the requirements considered to define the RFC API. > > 1) APIs similar to existing Ethernet and crypto API framework for > ○ Device creation, device Identification and device configuration > 2) Enumerate libeventdev resources as numbers(0..N) to > ○ Avoid ABI issues with handles > ○ Event device may have million flow queues so it's not practical to > have handles for each flow queue and its associated name based > lookup in multiprocess case > 3) Avoid struct mbuf changes > 4) APIs to > ○ Enumerate eventdev driver capabilities and resources > ○ Enqueue events from l-core > ○ Schedule events > ○ Synchronize events > ○ Maintain ingress order of the events > ○ Run to completion support > > Find below the URL for the complete API specification. > > https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h > > I have created a supportive document to share the concepts of > event driven programming model and proposed APIs details to get > better reach for the specification. > This presentation will cover introduction to event driven programming model concepts, > characteristics of hardware-based event manager devices, > RFC API proposal, example use case, and benefits of using the event driven programming model. > > Find below the URL for the supportive document. > > https://rawgit.com/jerinjacobk/libeventdev/master/DPDK-event_driven_programming_framework.pdf > > git repo for the above documents: > > https://github.com/jerinjacobk/libeventdev/ > > Looking forward to getting comments from both application and driver > implementation perspective. > Hi Jerin, thanks for the RFC. Packet distribution and scheduling is something we've been thinking about here too. This RFC gives us plenty of new ideas to take on board. :-) While you refer to HW implementations on SOC's, have you given any thought to how a pure-software implementation of an event API might work? I know that while a software implemenation can obviously be done for just about any API, I'd be concerned that the API not get in the way of a very highly tuned implementation. We'll look at it in some detail and get back to you with our feedback, as soon as we can, to start getting the discussion going. Regards, /Bruce