From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) by dpdk.org (Postfix) with ESMTP id 36E3BBD32 for ; Fri, 3 Mar 2017 17:45:05 +0100 (CET) Received: by mail-wr0-f172.google.com with SMTP id u108so77468682wrb.3 for ; Fri, 03 Mar 2017 08:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=x+irmIBGJjY8E8bBE+29uGXlvzD20Z+Zo2M8R2StO4E=; b=oRzNYTExK/X5c0/DNES3tbUMhWINbvDivdnrvIsaeoCrUgCENUHliJFpcYrk4/v3Rn UMsceOzVTjX2j6Q4dVrjwVvEjSM6+xpT7DwlbPoXml0J7xXN78bSGleP6UZge0d2q01+ XVg59PDS24cmjtFiAfZ+L+c9ND5Z+OVvfdM0JxdwG0u//QOUsFYaX2nXDa3kG7Hxcedx bV21oJscMRd8sgkEp21nWkPNkkojvPZ/hKntJOOQHupngbcJpdj3GiF+5fTU34xCQ+ix p9/r8Iz10gy/LbEuyCVDAxsVoMHtrC+2P/U//pMLvh6mKcrIctu27bz7EZ0etAiYa1mO JqMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=x+irmIBGJjY8E8bBE+29uGXlvzD20Z+Zo2M8R2StO4E=; b=B60saDma1g3jcBLtlKMOL8GD5uucEq+JPVlwqSLQR0FI+gJeMKSfnBORGOsHKZoCuf ULG8fK8PNJ57isvoZ6urRve7Xt2hpBP+HX9dz0uxdiC3ReCrrCyu47YhsDJjShJyDPA4 TiWIP3oGu0IaiuK+N0U1VaB/Yk7vKLQdZwWvgctCv1bPONDgfveidRtHzUHs4NMedHnS r3ionzkWDkfcrnURzIxAHPHWp4KORwiEGtMoXDvWGa3MC3Snhir6RpR2SaBmQcX/J3md /vXVuS6cNEgTbgDCsCjSz2iP5sEVSPzb+DeyQSEVMm2Rzep68mDY136Q8CRIgoX7hbxV bDpg== X-Gm-Message-State: AMke39lQ3t03Nd6xAV/QxwV7fyAGxB9+yK5dJpHeAuOr8fLCDhsny+5yqRkjNQbTzJJ4/OUh X-Received: by 10.223.171.239 with SMTP id s102mr3406536wrc.23.1488559504919; Fri, 03 Mar 2017 08:45:04 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id l138sm3725291wmd.7.2017.03.03.08.45.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Mar 2017 08:45:04 -0800 (PST) Date: Fri, 3 Mar 2017 17:45:01 +0100 From: Olivier Matz To: "Venkatesan, Venky" Cc: "Richardson, Bruce" , "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" Message-ID: <20170303174501.7dbfbf10@platinum> In-Reply-To: <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> <1FD9B82B8BF2CF418D9A1000154491D97F0072FD@ORSMSX102.amr.corp.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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:45:05 -0000 Hi Venky, On Fri, 3 Mar 2017 16:18:52 +0000, "Venkatesan, Venky" wrote: > > -----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 > > > > 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. > > > > The l3fwd example uses the rte_eth_rx_descriptor_done() API, which is very > > similar to what I'm adding here. The differences are: > > > > - the new lib provides a Tx counterpart > > - it differentiates done/avail/hold descriptors > > > > 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 > > > > About the usefulness of the API, I confirm it is useful: for instance, you can > > detect that you ring is more than half-full, and take dispositions to increase > > your processing power or select the packets you want to drop first. > > > For either of those cases, you could still implement this in your application without any of these APIs. Simply keep reading rx_burst() till it returns zero. You now have all the packets that you want - look at how many and increase your processing power, or drop them. In my use case, I may have several thresholds, so it gives a fast information about the ring status. Keeping reading rx_burst() until it returns 0 will not work if the packet rate is higher than (or close to) what the cpu is able to eat. > > The issue I have with this newer instantiation of the API is that it is essentially to pick up a descriptor at a specified offset. In most cases, if you 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 making it a costly API call. In cases that don't have something like Data Direct I/O (DDIO), you are now going to hit memory and stall the CPU for a long time. In any case, the API becomes pretty useless unless you want to stay within a smaller look ahead offset. The rx_burst() methodology simply works better in most circumstances, and allows application level control. > > So, NAK. My suggestion would be to go back to the older API. I don't understand the reason of your nack. The old API is there (for Rx it works the same), and it is illustrated in an example. Since your arguments also applies to the old API, so why are you saying we should keep the older API? For Tx, I want to know if I have enough room to send my packets before doing it. There is no API yet to do that. And yes, this could trigger cache misses, but in some situations it's preferable to be a bit slower (all tests are not test-iofwd) and be able to anticipate that the ring is getting full. Regards, Olivier