From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id AB28A1E31 for ; Wed, 2 Nov 2016 12:48:41 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP; 02 Nov 2016 04:48:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,583,1473145200"; d="scan'208";a="26551102" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.210.137]) by fmsmga005.fm.intel.com with SMTP; 02 Nov 2016 04:48:38 -0700 Received: by (sSMTP sendmail emulation); Wed, 02 Nov 2016 11:48:37 +0000 Date: Wed, 2 Nov 2016 11:48:37 +0000 From: Bruce Richardson To: Jerin Jacob Message-ID: <20161102114837.GC40328@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> <20161102080632.GA21820@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161102080632.GA21820@localhost.localdomain> 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" 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: Wed, 02 Nov 2016 11:48:42 -0000 On Wed, Nov 02, 2016 at 01:36:34PM +0530, Jerin Jacob wrote: > On Fri, Oct 28, 2016 at 01:48:57PM +0000, 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. > > > > OK. I will try to share my views on IP fragmentation on event _HW_ > models(at least on Cavium HW) then we can see, how we can converge. > > First, The fragmentation specific logic should be decoupled from the event > model as it specific to packet and L3 layer(Not specific to generic event) > I would view fragmentation as just one example of a workload like this, multicast and broadcast may be two other cases. Yes, they all apply to packet, but the general feature support is just how to provide support for one event generating multiple further events which should be linked together for reordering. [I think this only really applies in the reordered case - which leads to another question: in your experience do you see other event types other than packet being handled in a "reordered" manner?] /Bruce