From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Thu, 2 Mar 2017 17:14:59 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id 196so3694910wmm.1 for ; 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 To: Bruce Richardson 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 16:15:00 -0000 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. Regards Olivier