From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 0/6] get status of Rx and Tx descriptors Date: Mon, 06 Mar 2017 12:02:34 +0100 Message-ID: <5158489.C766vy8AX9@xps13> References: <1479981261-19512-1-git-send-email-olivier.matz@6wind.com> <1FD9B82B8BF2CF418D9A1000154491D97F007A8E@ORSMSX102.amr.corp.intel.com> <20170304214527.330cccde@platinum> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: "Venkatesan, Venky" , "Richardson, Bruce" , dev@dpdk.org, "Ananyev, Konstantin" , "Lu, Wenzhuo" , "Zhang, Helin" , "Wu, Jingjing" , "adrien.mazarguil@6wind.com" , "nelio.laranjeiro@6wind.com" , "Yigit, Ferruh" To: Olivier Matz Return-path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id C7A49952 for ; Mon, 6 Mar 2017 12:02:35 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id 196so17592780wmm.1 for ; Mon, 06 Mar 2017 03:02:35 -0800 (PST) In-Reply-To: <20170304214527.330cccde@platinum> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2017-03-04 21:45, Olivier Matz: > "Venkatesan, Venky" wrote: > > From: Olivier Matz > > > On Fri, 3 Mar 2017 16:18:52 +0000, "Venkatesan, Venky" wrote: > > > > From: Olivier Matz > > > > > 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: > > > > > > > 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) > > > > > > > [...] > > > > > > Are these really needed for real applications? I suspect our > > > > > > trivial l3fwd power example can be made to work ok without them. OK, please remove the use of such old API in the example. [...] > So, the penalty, in the worst case (burst of 32, 100c/pkt) is ~6%. > Given the information it provides, it is acceptable to me. Any penalty is acceptable, given it is not mandatory to call these functions. > Note we are talking here about an optional API, that would only impact > people that use it. Yes, it just brings more information and can be used for some debug measures. [...] > Also, changing the Rx burst function is much more likely to be refused > than adding an optional API. Yes, changing Rx/Tx API is not really an option and does not bring so much benefits. [...] > > > > 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? > > > > > > > I am not a fan of the old API either. In hindsight, it was a mistake > > (which we didn't catch in time). As Bruce suggested, the example > > should be reworked to work without the API, and deprecate it. Agreed to deprecate the old API. However, there is no relation with this new optional API. > Before deprecating an API, I think we should check if people are using > it and if it can really be replaced. I think there are many things that > could be deprecated before this one. Yes we can discuss a lot of things but let's focus on this one :) > > > 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. > > > > Yes. This could be a lightweight API if it returned a count (txq->nb_tx_free) instead of actually touching the ring, which is what I have a problem with. If the implementation changes to that, that may be okay to do. The Tx API has more merit than the Rx API, but not coded around an offset. > > Returning txq->nb_tx_free does not work because it is a software view, > which becomes wrong as soon as the hardware has send the packets. > Example: > 1. Send many packets at very high rate, the tx ring becomes full > 2. wait that packets are transmitted > 3. read nb_tx_free, it returns 0, which is not what I want > > So in my case there is a also a need for a Tx descriptor status API. > > Thomas, you are the maintainer of ethdev API, do you have an opinion? You show some benefits and it does not hurt any existing API. So we cannot reject such a feature, even if its best use is for debug or specific applications. I think the concern here was the fear of seeing this called in some benchmark applications. You just have to highlight in the API doc that there are some performance penalties.