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 50471A04B1; Fri, 28 Aug 2020 12:07:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 818091C0DB; Fri, 28 Aug 2020 12:07:33 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 914B71C0CA for ; Fri, 28 Aug 2020 12:07:31 +0200 (CEST) IronPort-SDR: C9/+Kgytl68OG8j8pDZn49Z+EQEe67pneNksmuYy3U0DAo2N8vdxgnx9pg6CZ6NMCVwaiQT3lG 6qIcnN9ZHuxw== X-IronPort-AV: E=McAfee;i="6000,8403,9726"; a="144316056" X-IronPort-AV: E=Sophos;i="5.76,363,1592895600"; d="scan'208";a="144316056" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Aug 2020 03:07:25 -0700 IronPort-SDR: GHzBnbkFqjnghFTyIoXlAAmWa1J3ZniERCvDgMOgw1PNnoHxIHfMslUYBL8TIb/zpGePTWrwkC VXTZ7JrF0cFw== X-IronPort-AV: E=Sophos;i="5.76,363,1592895600"; d="scan'208";a="475622388" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.22.193]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 28 Aug 2020 03:07:22 -0700 Date: Fri, 28 Aug 2020 11:07:19 +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: <20200828100719.GA575@bricha3-MOBL.ger.corp.intel.com> References: <20200827075452.1751-1-jia.guo@intel.com> <98CBD80474FA8B44BF855DF32C47DC35C61257@smartserver.smartshare.dk> <20200827090944.GA569@bricha3-MOBL.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC35C6125A@smartserver.smartshare.dk> <20200827094333.GC569@bricha3-MOBL.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC35C6125B@smartserver.smartshare.dk> <20200827114117.GD569@bricha3-MOBL.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC35C61261@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61261@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] [RFC] ethdev: rte_eth_rx_burst() requirements fornb_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 Fri, Aug 28, 2020 at 11:03:59AM +0200, Morten Brørup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > > > > > > Right. For now then, it seems like just documenting a minimum burst > > size is > > reasonable. > > I agree. It is so far from the spirit of DPDK to call rte_eth_rx_burst() with a small nb_pkts that the driver developers didn't even consider it. The API documentation needs fixing, not the drivers. > > It doesn't take care of your example 4 packet latency sensitive application, though. Which BTW also doesn’t work today on drivers with vector support. So it might not be a real world scenario anyway. :-) > AFAIK, 8 is the smallest burst guaranteed to work everywhere, but I think just about everything bar the AVX2 i40e code path also supports 4 as a burst size. Therefore adjusting to 4 as min-burst might well be reasonable. /Bruce