From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id CDF7BF95B for ; Fri, 3 Mar 2017 17:18:53 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP; 03 Mar 2017 08:18:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,237,1484035200"; d="scan'208";a="1104447396" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by orsmga001.jf.intel.com with ESMTP; 03 Mar 2017 08:18:52 -0800 Received: from orsmsx102.amr.corp.intel.com ([169.254.3.228]) by ORSMSX109.amr.corp.intel.com ([169.254.11.220]) with mapi id 14.03.0248.002; Fri, 3 Mar 2017 08:18:52 -0800 From: "Venkatesan, Venky" To: Olivier Matz , "Richardson, Bruce" CC: "dev@dpdk.org" , "thomas.monjalon@6wind.com" , "Ananyev, Konstantin" , "Lu, Wenzhuo" , "Zhang, Helin" , "Wu, Jingjing" , "adrien.mazarguil@6wind.com" , "nelio.laranjeiro@6wind.com" , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] [PATCH 0/6] get status of Rx and Tx descriptors Thread-Index: AQHSkrAobLfqZIwC9keND6chLEfjXqGCNRKAgAAL7QCAAQrVUA== Date: Fri, 3 Mar 2017 16:18:52 +0000 Message-ID: <1FD9B82B8BF2CF418D9A1000154491D97F0072FD@ORSMSX102.amr.corp.intel.com> References: <1479981261-19512-1-git-send-email-olivier.matz@6wind.com> <1488388752-1819-1-git-send-email-olivier.matz@6wind.com> <20170302153215.GA173492@bricha3-MOBL3.ger.corp.intel.com> <20170302171456.52a9415b@platinum> In-Reply-To: <20170302171456.52a9415b@platinum> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjk4ODBlNGMtYTNkYy00ZWM2LTllN2MtYjJjOTRhNjcxN2I3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImdqOXR5THRIXC9OYm1oTFdRb0huQ1RLOURDbVVabWthTTdWT2dmT1JXV3pRPSJ9 x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Fri, 03 Mar 2017 16:18:54 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz > Sent: Thursday, March 2, 2017 8:15 AM > To: Richardson, Bruce > Cc: dev@dpdk.org; thomas.monjalon@6wind.com; Ananyev, Konstantin > ; Lu, Wenzhuo ; > Zhang, Helin ; Wu, Jingjing > ; adrien.mazarguil@6wind.com; > nelio.laranjeiro@6wind.com; Yigit, Ferruh > Subject: Re: [dpdk-dev] [PATCH 0/6] get status of Rx and Tx descriptors >=20 > On Thu, 2 Mar 2017 15:32:15 +0000, Bruce Richardson > wrote: > > 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. >=20 > The l3fwd example uses the rte_eth_rx_descriptor_done() API, which is ver= y > similar to what I'm adding here. The differences are: >=20 > - the new lib provides a Tx counterpart > - it differentiates done/avail/hold descriptors >=20 > The alternative was to update the descriptor_done API, but I think we > agreed to do that in this thread: > http://www.dpdk.org/ml/archives/dev/2017-January/054947.html >=20 > About the usefulness of the API, I confirm it is useful: for instance, yo= u can > detect that you ring is more than half-full, and take dispositions to inc= rease > your processing power or select the packets you want to drop first. >=20 For either of those cases, you could still implement this in your applicati= on without any of these APIs. Simply keep reading rx_burst() till it return= s zero. You now have all the packets that you want - look at how many and i= ncrease your processing power, or drop them.=20 The issue I have with this newer instantiation of the API is that it is ess= entially to pick up a descriptor at a specified offset. In most cases, if y= ou plan to read far enough ahead with the API (let's say 16 or 32 ahead, or= even more), you are almost always guaranteed an L1/L2 miss - essentially m= aking it a costly API call. In cases that don't have something like Data Di= rect I/O (DDIO), you are now going to hit memory and stall the CPU for a lo= ng time. In any case, the API becomes pretty useless unless you want to sta= y within a smaller look ahead offset. The rx_burst() methodology simply wor= ks better in most circumstances, and allows application level control. So, NAK. My suggestion would be to go back to the older API. -Venky > Regards > Olivier