From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
 by dpdk.org (Postfix) with ESMTP id 79AFC2B9D
 for <dev@dpdk.org>; Thu,  2 Mar 2017 17:14:59 +0100 (CET)
Received: by mail-wm0-f45.google.com with SMTP id 196so3694910wmm.1
 for <dev@dpdk.org>; Thu, 02 Mar 2017 08:14:59 -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=rMi9nEJhB9itc5FSmnqMHMbYdKGARY1MS7lBbDk6c/I=;
 b=Svq3MJyZ4KdL8N/s4KDVMu5fzVkC/COZ+/UMj2lBrahDwp7uB7iIYvdIl5ry52wA27
 tZ5EsAlUVlYwaYW04YAw8sREnZzvJHvEIPmGi1BAlKfNXyQSZtAkWQyXec4forCQKG6r
 avGHbn4XVHBEUW60uTDhsuWRIw9lOIehh+msKVwqvxDBCfUhyarsvTf2DDVhUO+KOV1c
 N/hccWQoyAj0hgseGFiVcLwn7UAj66enEjNLWF1SAJFJMJz1d/RoaEEj2bTuDcwnvTD5
 PhYRGlzKhGmoj+1R9HXCGDwP4wu5Rc81wwbVmXB2XDpf+mYVMqaeOzi7ZIIbXYBZIk3w
 QnLw==
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=rMi9nEJhB9itc5FSmnqMHMbYdKGARY1MS7lBbDk6c/I=;
 b=dOnV5D0jYuJFGg92yV2GWBnrbNIH3XadVF4TV1J7zA/6CnVCXjKzHgmrMN4P/C+r3b
 ObfCDCN0Hf0D1x/LVaKrfBJFg0k24pirV/vFt0VWJZnn/RkDenGJOEq5+bfvO9i5ESm6
 HZV9kcQmRW73IucQCtYpLRfaJjtkWQ/ooYSfXyjcP3BMaC6V0tb8HPyOaz6YoVREXr2o
 m0xtzLc8C7DiFMGChgDH2aK1KRbRuGrd5ML4nqOsBhtJ7cxptSY8dNZGmwJLIykcj0Pf
 QfjP8ChO2+Uy+MMORstKzNTJqCa4Vi8bPnvD2G5RIARpaOpxuPIbRZao7J2wD33R5y6s
 plyQ==
X-Gm-Message-State: AMke39ka7AJcrA4NEmR5Jg0JxufGzkgNIiR8CRm7+S91O8pnEdinWpQJYHr/2Mr3cQ1C6iy2
X-Received: by 10.28.137.211 with SMTP id l202mr8842761wmd.118.1488471299709; 
 Thu, 02 Mar 2017 08:14:59 -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 e74sm11819681wmd.2.2017.03.02.08.14.59
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Thu, 02 Mar 2017 08:14:59 -0800 (PST)
Date: Thu, 2 Mar 2017 17:14:56 +0100
From: Olivier Matz <olivier.matz@6wind.com>
To: Bruce Richardson <bruce.richardson@intel.com>
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: <20170302171456.52a9415b@platinum>
In-Reply-To: <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>
 <20170302153215.GA173492@bricha3-MOBL3.ger.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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 16:15:00 -0000

On Thu, 2 Mar 2017 15:32:15 +0000, Bruce Richardson <bruce.richardson@intel.com> 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.

Regards
Olivier