From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1F187A04B1; Fri, 28 Aug 2020 08:39:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 06B2A1C0B3; Fri, 28 Aug 2020 08:39:41 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 1B3181C0B2 for ; Fri, 28 Aug 2020 08:39:38 +0200 (CEST) IronPort-SDR: gN6WDeYCq7zNVSAaKeJ/SpvosTwR7GaRhDpJKFOx4DPv/NW31q6AOCzSsU0Tr59PJjWAoLyoGa w/zRrqtPayLg== X-IronPort-AV: E=McAfee;i="6000,8403,9726"; a="144292184" X-IronPort-AV: E=Sophos;i="5.76,362,1592895600"; d="scan'208";a="144292184" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Aug 2020 23:39:38 -0700 IronPort-SDR: 1u+Fda13PaH+Tts1IOjGrvVVV5vBRg2gmjWvvXIWVRSOOuabxjm6wFh0vrgPQnvTpZ4jLoCIB7 XkELZkbpQ+EA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,362,1592895600"; d="scan'208";a="500920230" Received: from jguo15x-mobl.ccr.corp.intel.com (HELO [10.67.68.181]) ([10.67.68.181]) by fmsmga005.fm.intel.com with ESMTP; 27 Aug 2020 23:39:34 -0700 To: "Wang, Haiyue" , =?UTF-8?Q?Morten_Br=c3=b8rup?= , "Yang, Qiming" , "Xing, Beilei" , "Zhao1, Wei" , "Zhang, Qi Z" , "Wu, Jingjing" Cc: "Richardson, Bruce" , "dev@dpdk.org" , "Zhang, Helin" , "Yigit, Ferruh" , "barbette@kth.se" References: <20200827101008.76906-1-jia.guo@intel.com> <98CBD80474FA8B44BF855DF32C47DC35C6125C@smartserver.smartshare.dk> From: Jeff Guo Message-ID: <77c760bb-7034-72b6-d4ba-c970764b7f3d@intel.com> Date: Fri, 28 Aug 2020 14:39:33 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 8/28/2020 10:06 AM, Wang, Haiyue wrote: >> -----Original Message----- >> From: dev On Behalf Of Morten Brørup >> Sent: Thursday, August 27, 2020 20:38 >> To: Guo, Jia ; Yang, Qiming ; Xing, Beilei >> ; Zhao1, Wei ; Zhang, Qi Z ; Wu, >> Jingjing >> Cc: Richardson, Bruce ; dev@dpdk.org; Zhang, Helin ; >> Yigit, Ferruh ; barbette@kth.se >> Subject: Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs >> >>> From: Jeff Guo [mailto:jia.guo@intel.com] >>> Sent: Thursday, August 27, 2020 12:10 PM >>> >>> The limitation of burst size in vector rx was removed, since it should >>> retrieve as much received packets as possible. And also the scattered >>> receive path should use a wrapper function to achieve the goal of >>> burst maximizing. >>> >>> This patch set aims to maximize vector rx burst for for >>> ixgbe/i40e/ice/iavf/fm10k PMDs. >>> >>> v2->v1: >>> 1:add fm10k driver case >>> 2:refine some doc >>> >> I now noticed that the vector functions also does: >> nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP); >> >> I am not sure about this, but if I read it correctly, calling rte_eth_rx_burst() with nb_pkts = 33 >> (not 32) would only return 32 packets, even if more packets are available. (I assume that >> RTE_I40E_DESCS_PER_LOOP is 32.) In this case, I guess that you need to read the remaining of the >> requested packets using the non-vector function in order to support any nb_pkts value. >> > This is vector instruction handling design requirement, like for avx2: #define ICE_DESCS_PER_LOOP_AVX 8, > if deep into the real loop handling, you will get the point why doing RTE_ALIGN_FLOOR. ;-) > > _ice_recv_raw_pkts_vec_avx2: > for (i = 0, received = 0; i < nb_pkts; i += ICE_DESCS_PER_LOOP_AVX, rxdp += ICE_DESCS_PER_LOOP_AVX) > > Maybe it is worth to tell PMD to stop using vector by calling rte_eth_rx_queue_setup with the application > burst size it wants. > >> That is, unless the rte_eth_rx_burst() API is extended with requirements to nb_pkts, as discussed in >> the other thread: >> http://inbox.dpdk.org/dev/20200827114117.GD569@bricha3- >> MOBL.ger.corp.intel.com/T/#mc8051e9022d6aeb20c51c5a226b2274d3d6d4266 Agree with above haiyue said, and go through the discuss on the thread, i think vector path was born definitely for the spirit of dpdk, each driver could keep the performance base on the instinct requirement and define what is the specific "max", the path option could give to app, it could static choose one when set up queue or dynamic but not the driver scope, document could be add to AVI if need for benefit user. >> >> Med venlig hilsen / kind regards >> - Morten Brørup >> >>