From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 21D35282 for ; Mon, 13 Feb 2017 11:38:59 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2017 02:38:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,156,1484035200"; d="scan'208";a="58049272" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by orsmga004.jf.intel.com with SMTP; 13 Feb 2017 02:38:56 -0800 Received: by (sSMTP sendmail emulation); Mon, 13 Feb 2017 10:38:55 +0000 Date: Mon, 13 Feb 2017 10:38:55 +0000 From: Bruce Richardson To: Gage Eads Cc: dev@dpdk.org, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, harry.van.haaren@intel.com, nipun.gupta@nxp.com Message-ID: <20170213103854.GB377356@bricha3-MOBL3.ger.corp.intel.com> References: <1486760541-12568-1-git-send-email-gage.eads@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1486760541-12568-1-git-send-email-gage.eads@intel.com> 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) Subject: Re: [dpdk-dev] [PATCH] eventdev: Add rte_errno return values to the enqueue and dequeue functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 10:39:00 -0000 On Fri, Feb 10, 2017 at 03:02:21PM -0600, Gage Eads wrote: > This change allows user software to differentiate between an invalid argument > (such as an invalid queue_id or sched_type in an enqueued event) and > backpressure from the event device. > > The port and device ID checks are placed in RTE_LIBRTE_EVENTDEV_DEBUG header > guards to avoid the performance hit in non-debug execution. > > Signed-off-by: Gage Eads > --- Do we have some idea of the performance hit from these? It may be too soon to know, given we don't have many drivers to test with, but if there is no perf hit seen with the SW driver, I think we should look to just always do this, rather than having it compile-time off. If it does prove to be a performance problem we can look to #ifdef it out later. /Bruce