From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=S95kY0FzrEIpE75PTWMm/k3+rtiMgqxJTZtbpP7Vc04=; b=gUKFV4Z24u+Q/Czx5zDEZobSTC4p06M6zOteFv80YgIEdLBm8yyeKAqZcyIs7zfma5 cx0tNZzG8iaLb+HJrdjRcWyMa9nnLRpXyUvYf/UPVcbjnnhfnNDKMzy/gR4rkB9kkrXS QrtnDHvs6nJwwwa3ci6zS1XKJW9hykzwx6gMGEPuW7xSw2c/1UZeOUBGBNxcN09Zzpwi 4d98kQXXN1o1yt7LsjQCwDL54ROzsPFjhC2QTd4R1wzalXzh2ZjqBLOkxudXS10c+kWT Jmj1ju2a2BTw53/8Iv+c99yewWlq4y46UkX3BgrY1VVHFO2dAvG9ZePrY4PidSATIAZU ctrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=S95kY0FzrEIpE75PTWMm/k3+rtiMgqxJTZtbpP7Vc04=; b=dHXoqhN6CyUOHIKKyGAugf2mc07xbq2lMV0w/izhl2obrjG9XY8kIlR5O1ureUcCqW 9yt813CgPPoGZdLamhY8xyp258vTgJIhnqFaW6Xs6Cn86TlaW++sNPiHvtJeqXbKhu/r tHqiPWPoFZOUeRppgsZZL10onJ9yG8UIkDnVPbVXoGMJXkzQStHEbKsLKUSj6SxdOZ5W ktrizbX8Y8IOaUV4LTjyv+2bkxKxQfgJXx5YlC8UPN9bzUzSTvr8d1xoJ97vIv6BFwf0 mpqibjxPxm8Ie/hzvqqvLuJ1gZvNNWUg+2tGMtOao4A2pIgQtmXR6wNoAb5zp+rmjys6 6C5Q== X-Gm-Message-State: AMke39lwP1ni47u0/C+HgwvqecF+eZ7MFWDgVc1+uYUpouGK3HuIp12SpY0s2xTyxAl91crZ X-Received: by 10.28.7.20 with SMTP id 20mr12075455wmh.115.1488798155612; Mon, 06 Mar 2017 03:02:35 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id c58sm26592598wrc.9.2017.03.06.03.02.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 03:02:35 -0800 (PST) From: Thomas Monjalon To: Olivier Matz 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" Date: Mon, 06 Mar 2017 12:02:34 +0100 Message-ID: <5158489.C766vy8AX9@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20170304214527.330cccde@platinum> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Mon, 06 Mar 2017 11:02:36 -0000 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.