From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 7AA3F2C60 for ; Thu, 2 Mar 2017 16:32:21 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2017 07:32:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,231,1484035200"; d="scan'208";a="1117591443" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by fmsmga001.fm.intel.com with SMTP; 02 Mar 2017 07:32:17 -0800 Received: by (sSMTP sendmail emulation); Thu, 02 Mar 2017 15:32:16 +0000 Date: Thu, 2 Mar 2017 15:32:15 +0000 From: Bruce Richardson To: Olivier Matz Cc: dev@dpdk.org, thomas.monjalon@6wind.com, konstantin.ananyev@intel.com, wenzhuo.lu@intel.com, helin.zhang@intel.com, jingjing.wu@intel.com, adrien.mazarguil@6wind.com, nelio.laranjeiro@6wind.com, ferruh.yigit@intel.com Message-ID: <20170302153215.GA173492@bricha3-MOBL3.ger.corp.intel.com> References: <1479981261-19512-1-git-send-email-olivier.matz@6wind.com> <1488388752-1819-1-git-send-email-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1488388752-1819-1-git-send-email-olivier.matz@6wind.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.0 (2017-02-23) Subject: Re: [dpdk-dev] [PATCH 0/6] get status of Rx and Tx descriptors 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: Thu, 02 Mar 2017 15:32:21 -0000 On Wed, Mar 01, 2017 at 06:19:06PM +0100, Olivier Matz wrote: > This patchset introduces a new ethdev API: > - rte_eth_rx_descriptor_status() > - rte_eth_tx_descriptor_status() > > The Rx API is aims to replace rte_eth_rx_descriptor_done() which > does almost the same, but does not differentiate the case of a > descriptor used by the driver (not returned to the hw). > > The usage of these functions can be: > - on Rx, anticipate that the cpu is not fast enough to process > all incoming packets, and take dispositions to solve the > problem (add more cpus, drop specific packets, ...) > - on Tx, detect that the link is overloaded, and take dispositions > to solve the problem (notify flow control, drop specific > packets) > Looking at it from a slightly higher level, are these APIs really going to help in these situations? If something is overloaded, doing more work by querying the ring status only makes things worse. I suspect that in most cases better results can be got by just looking at the results of RX and TX burst functions. For example, if RX burst is always returning a full set of packets, chances are you are overloaded, or at least have no scope for an unexpected burst or event. Are these really needed for real applications? I suspect our trivial l3fwd power example can be made to work ok without them. Regards, /Bruce