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 06D3A8DA2 for ; Wed, 28 Oct 2015 11:44:40 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 28 Oct 2015 03:44:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,209,1444719600"; d="scan'208";a="589558614" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.61]) by FMSMGA003.fm.intel.com with SMTP; 28 Oct 2015 03:44:38 -0700 Received: by (sSMTP sendmail emulation); Wed, 28 Oct 2015 10:44:37 +0025 Date: Wed, 28 Oct 2015 10:44:37 +0000 From: Bruce Richardson To: "Polehn, Mike A" Message-ID: <20151028104437.GA8052@bricha3-MOBL3> References: <745DB4B8861F8E4B9849C970520ABBF14974C1DF@ORSMSX102.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <745DB4B8861F8E4B9849C970520ABBF14974C1DF@ORSMSX102.amr.corp.intel.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [Patch] Eth Driver: Optimization for improved NIC processing rates 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, 28 Oct 2015 10:44:41 -0000 On Tue, Oct 27, 2015 at 08:56:31PM +0000, Polehn, Mike A wrote: > Prefetch of interface access variables while calling into driver RX and TX subroutines. > > For converging zero loss packet task tests, a small drop in latency for zero loss measurements > and small drop in lost packet counts for the lossy measurement points was observed, > indicating some savings of execution clock cycles. > Hi Mike, the commit log message above seems a bit awkward to read. If I understand it correctly, would the below suggestion be a shorter, clearer equivalent? Prefetch RX and TX queue variables in ethdev before driver function call This has been measured to produce higher throughput and reduced latency in RFC 2544 throughput tests. Or perhaps you could suggest yourself some similar wording. It would also be good to clarify with what applications the improvements were seen - was it using testpmd or l3fwd or something else? Regards, /Bruce