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 CFB951B170 for ; Wed, 10 Jan 2018 15:39:02 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2018 06:39:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,340,1511856000"; d="scan'208";a="9661448" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.77]) by orsmga008.jf.intel.com with SMTP; 10 Jan 2018 06:38:58 -0800 Received: by (sSMTP sendmail emulation); Wed, 10 Jan 2018 14:38:58 +0000 Date: Wed, 10 Jan 2018 14:38:57 +0000 From: Bruce Richardson To: Vincent JARDIN Cc: John Fastabend , "Zhang, Qi Z" , "Xing, Beilei" , "dev@dpdk.org" , "Zhang, Helin" , "Yigit, Ferruh" Message-ID: <20180110143857.GA12784@bricha3-MOBL3.ger.corp.intel.com> References: <20171123165314.168786-1-bruce.richardson@intel.com> <20180109143254.234428-1-bruce.richardson@intel.com> <59AF69C657FD0841A61C55336867B5B0722203E8@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.1 (2017-09-22) Subject: Re: [dpdk-dev] [PATCH v2 0/2] AVX2 Vectorized Rx/Tx functions for i40e 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: Wed, 10 Jan 2018 14:39:03 -0000 On Wed, Jan 10, 2018 at 03:25:23PM +0100, Vincent JARDIN wrote: > Le 10/01/2018 à 10:27, Richardson, Bruce a écrit : > > > Hi Bruce, > > > > > > Just curious, can you provide some hints on percent increase in at least > > > some representative cases? I'm just trying to get a sense of if this is > > > %5, 10%, 20%, more... I know mileage will vary depending on system, setup, > > > configuration, etc. > > > > > Best case conditions to test under are using testpmd as that is where any IO improvement will be most seen. As a ballpark figure though, on my system while testing testpmd with both 16B and 32B descriptors, (RX/TX ring sizes 1024/512) I saw ~15% performance increase, and sometimes quite a bit higher, e.g. when testing with 16B descriptors with larger burst sizes. > > Hi Bruce, > > Then, about the next limit after this performance increase: is it the > board/Mpps capacity/PCI bus? If so, you should see that CPU usage on > testpmd's cores to be decreased. Can you be more explicit about it? > Hi Vincent, again it really depends on your setup. In my case I was using 2 NICs with 1x40G ports each, and each one using a PCI Gen3 x8 connection to CPU. I chose this particular setup because there is sufficient NIC capacity and PCI bandwidth available that for 64-byte packet sizes, there will be more IO available than a single core can handle. This patchset basically reduces the cycles needed for a core to process each packet, so in cases where the core is the bottleneck you will get improved performance. For other cases where PCI or NIC capability is the issue this patch almost certainly won't help, as there are no changes to the way in which the NIC descriptor ring is used, e.g. no changes to descriptor write-back over PCI etc. > What's about other packet size like 66 bytes? 122 bytes? which are not > aligned on 64 bytes. > Sorry, I don't have comparison data for that to share. /Bruce