From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 4B2C52BA3 for ; Fri, 28 Oct 2016 10:36:51 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP; 28 Oct 2016 01:36:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,557,1473145200"; d="scan'208";a="895020410" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.210.150]) by orsmga003.jf.intel.com with SMTP; 28 Oct 2016 01:36:47 -0700 Received: by (sSMTP sendmail emulation); Fri, 28 Oct 2016 09:36:46 +0100 Date: Fri, 28 Oct 2016 09:36:46 +0100 From: Bruce Richardson To: Jerin Jacob Message-ID: <20161028083646.GA82872@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> <20161026122416.GA21509@localhost.localdomain> <20161026125414.GB33288@bricha3-MOBL3.ger.corp.intel.com> <20161028030140.GA2967@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161028030140.GA2967@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" , "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 08:36:51 -0000 On Fri, Oct 28, 2016 at 08:31:41AM +0530, Jerin Jacob wrote: > On Wed, Oct 26, 2016 at 01:54:14PM +0100, Bruce Richardson wrote: > > On Wed, Oct 26, 2016 at 05:54:17PM +0530, Jerin Jacob wrote: > > > On Wed, Oct 26, 2016 at 12:11:03PM +0000, Van Haaren, Harry wrote: > > > > > -----Original Message----- > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob > > Thanks. One other suggestion is that it might be useful to provide > > support for having typed queues explicitly in the API. Right now, when > > you create an queue, the queue_conf structure takes as parameters how > > many atomic flows that are needed for the queue, or how many reorder > > slots need to be reserved for it. This implicitly hints at the type of > > traffic which will be sent to the queue, but I'm wondering if it's > > better to make it explicit. There are certain optimisations that can be > > looked at if we know that a queue only handles packets of a particular > > type. [Not having to handle reordering when pulling events from a core > > can be a big win for software!]. > > If it helps in SW implementation, then I think we can add this in queue > configuration. > > > > > How about adding: "allowed_event_types" as a field to > > rte_event_queue_conf, with possible values: > > * atomic > > * ordered > > * parallel > > * mixed - allowing all 3 types. I think allowing 2 of three types might > > make things too complicated. > > > > An open question would then be how to behave when the queue type and > > requested event type conflict. We can either throw an error, or just > > ignore the event type and always treat enqueued events as being of the > > queue type. I prefer the latter, because it's faster not having to > > error-check, and it pushes the responsibility on the app to know what > > it's doing. > > How about making default as "mixed" and let application configures what > is not required?. That way application responsibility is clear. > something similar to ETH_TXQ_FLAGS_NOMULTSEGS, ETH_TXQ_FLAGS_NOREFCOUNT > with default. > I suppose it could work, but why bother doing that? If an app knows it's only going to use one traffic type, why not let it just state what it will do rather than try to specify what it won't do. If mixed is needed, then it's easy enough to specify - and we can make it the zero/default value too. Our software implementation for now, only supports one type per queue - which we suspect should meet a lot of use-cases. We'll have to see about adding in mixed types in future. /Bruce