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 C758BA04B1; Thu, 27 Aug 2020 11:09:53 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E93B61C11F; Thu, 27 Aug 2020 11:09:52 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 1CF481C11C for ; Thu, 27 Aug 2020 11:09:50 +0200 (CEST) IronPort-SDR: oLkwA3/pWVbr2rblvdSBzMYfXECLCB99hFssE0Ct5KW3AK+4IV35XuW+4sGsl2OKYSrU/oeBWA o8GJpPRImCRw== X-IronPort-AV: E=McAfee;i="6000,8403,9725"; a="220700911" X-IronPort-AV: E=Sophos;i="5.76,359,1592895600"; d="scan'208";a="220700911" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Aug 2020 02:09:49 -0700 IronPort-SDR: byLRj2Sy7cZ7K9Vakf6z9iGFiVP5zrq/d9oab8gNMyk6a97ODLRPVTe8AiGpaL+HDRhf1/Znwt 957PCJvRbqBg== X-IronPort-AV: E=Sophos;i="5.76,359,1592895600"; d="scan'208";a="475131760" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.94.132]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 27 Aug 2020 02:09:47 -0700 Date: Thu, 27 Aug 2020 10:09:44 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Jeff Guo , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , qiming.yang@intel.com, beilei.xing@intel.com, wei.zhao1@intel.com, qi.z.zhang@intel.com, jingjing.wu@intel.com, dev@dpdk.org, helin.zhang@intel.com, barbette@kth.se Message-ID: <20200827090944.GA569@bricha3-MOBL.ger.corp.intel.com> References: <20200827075452.1751-1-jia.guo@intel.com> <98CBD80474FA8B44BF855DF32C47DC35C61257@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61257@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] [RFC] ethdev: rte_eth_rx_burst() requirements for nb_pkts 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 Thu, Aug 27, 2020 at 10:40:11AM +0200, Morten Brørup wrote: > Jeff and Ethernet API maintainers Thomas, Ferruh and Andrew, > > I'm hijacking this patch thread to propose a small API modification that prevents unnecessarily performance degradations. > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jeff Guo > > Sent: Thursday, August 27, 2020 9:55 AM > > > > 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 PMDs. > > > > Now I'm going to be pedantic and say that it still doesn't conform to the rte_eth_rx_burst() API, because the API does not specify any minimum requirement for nb_pkts. > > In theory, that could also be fixed in the driver by calling the non-vector function from the vector functions if nb_pkts is too small for the vector implementation. > > However, I think that calling rte_eth_rx_burst() with a small nb_pkts is silly and not in the spirit of DPDK, and introducing an additional comparison for a small nb_pkts in the driver vector functions would degrade their performance (only slightly, but anyway). > Actually, I'd like to see a confirmed measurement showing a slowdown before we discard such an option. :-) While I agree that using small bursts is not keeping with the design approach of DPDK of using large bursts to amortize costs and allow prefetching, there are cases where a user/app may want a small burst size, e.g. 4, for latency reasons, and we need a way to support that. Since the path selection is dynamic, we need to either: a) provide a way for the user to specify that they will use smaller bursts and so that vector functions should not be used b) have the vector functions transparently fallback to the scalar ones if used with smaller bursts Of these, option b) is simpler, and should be low cost since any check is just once per burst, and - assuming an app is written using the same request-size each time - should be entirely predictable after the first call. /Bruce