From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 2D5C056A2 for ; Fri, 28 Oct 2016 16:18:22 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 28 Oct 2016 07:16:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,410,1473145200"; d="scan'208";a="1051719644" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.210.150]) by orsmga001.jf.intel.com with SMTP; 28 Oct 2016 07:16:19 -0700 Received: by (sSMTP sendmail emulation); Fri, 28 Oct 2016 15:16:18 +0100 Date: Fri, 28 Oct 2016 15:16:18 +0100 From: Bruce Richardson To: "Van Haaren, Harry" Message-ID: <20161028141617.GA97736@bricha3-MOBL3.ger.corp.intel.com> References: <20161005072451.GA2358@localhost.localdomain> <1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com> <20161025174904.GA18333@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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) Cc: "Vangati, Narender" , "dev@dpdk.org" , "Eads, Gage" , "thomas.monjalon@6wind.com" Subject: Re: [dpdk-dev] [RFC] [PATCH v2] 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: Fri, 28 Oct 2016 14:18:22 -0000 On Fri, Oct 28, 2016 at 02:48:57PM +0100, Van Haaren, Harry wrote: > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob > > Sent: Tuesday, October 25, 2016 6:49 PM > > > > > Hi Community, > > > > So far, I have received constructive feedback from Intel, NXP and Linaro folks. > > Let me know, if anyone else interested in contributing to the definition of eventdev? > > > > If there are no major issues in proposed spec, then Cavium would like work on > > implementing and up-streaming the common code(lib/librte_eventdev/) and > > an associated HW driver.(Requested minor changes of v2 will be addressed > > in next version). > > > Hi All, > > I've been looking at the eventdev API from a use-case point of view, and I'm unclear on a how the API caters for two uses. I have simplified these as much as possible, think of them as a theoretical unit-test for the API :) > > > Fragmentation: > 1. Dequeue 8 packets > 2. Process 2 packets > 3. Processing 3rd, this packet needs fragmentation into two packets > 4. Process remaining 5 packets as normal > > What function calls does the application make to achieve this? > In particular, I'm referring to how can the scheduler know that the 3rd packet is the one being fragmented, and how to keep packet order valid. > > > Dropping packets: > 1. Dequeue 8 packets > 2. Process 2 packets > 3. Processing 3rd, this packet needs to be dropped > 4. Process remaining 5 packets as normal > > What function calls does the application make to achieve this? > Again, in particular how does the scheduler know that the 3rd packet is being dropped. > > > Regards, -Harry Hi, these questions apply particularly to reordered which has a lot more complications than the other types in terms of sending packets back into the scheduler. However, atomic types will still suffer from problems with things the way they are - again if we assume a burst of 8 packets, then to forward those packets, we need to re-enqueue them again to the scheduler, and also then send 8 releases to the scheduler as well, to release the atomic locks for those packets. This means that for each packet we have to send two messages to a scheduler core, something that is really inefficient. This number of messages is critical for any software implementation, as the cost of moving items core-to-core is going to be a big bottleneck (perhaps the biggest bottleneck) in the system. It's for this reason we need to use burst APIs - as with rte_rings. How we have solved this in our implementation, is to allow there to be an event operation type. The four operations we implemented are as below (using packet as a synonym for event here, since these would mostly apply to packets flowing through a system): * NEW - just a regular enqueue of a packet, without any previous context * FORWARD - enqueue a packet, and mark the flow processing for the equivalent packet that was dequeued as completed, i.e. release any atomic locks, or reorder this packet with respect to any other outstanding packets from the event queue. * DROP - this is roughtly equivalent to the existing "release" API call, except that having it as an enqueue type allows us to release multiple items in a single call, and also to mix releases with new packets and forwarded packets * PARTIAL - this indicates that the packet being enqueued should be treated according to the context of the current packet, but that that context should not be released/completed by the enqueue of this packet. This only really applies for reordered events, and is needed to do fragmentation and or multicast of packets with reordering. Therefore, I think we need to use some of the bits just freed up in the event structure to include an enqueue operation type. Without it, I just can't see how the API can ever support burst operation on packets. Regards, /Bruce