From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 17732A05D3 for ; Tue, 26 Mar 2019 10:29:15 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E2644326D; Tue, 26 Mar 2019 10:29:14 +0100 (CET) Received: from mail-vs1-f67.google.com (mail-vs1-f67.google.com [209.85.217.67]) by dpdk.org (Postfix) with ESMTP id 51CF2324D for ; Tue, 26 Mar 2019 10:29:13 +0100 (CET) Received: by mail-vs1-f67.google.com with SMTP id g127so7204419vsd.6 for ; Tue, 26 Mar 2019 02:29:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vu1nHZVAIhgFzfdFWPLyxYQ4MJ9xUyfEF28Ap1r7+vs=; b=lfY38cIiOdB+j78oBfnBBFd6WIBgOa+S/A0mecJbeLGfY8b0HL/ksI9ycpfzCPv+qQ 8NfXDcx/Y1YPAFIr4SZZZOVAIbL4R6HObSgE+hcuHaP9DIdTthIoEg00eHGnlf7tlsnu +wwZ44zNyNOswXZXte85DEidrWxAfbcyJzh0C7anpPe0zKyoHms9RJtcnthpM+9pH4sV RokhAVcjS6RCDhdb/inpo9MK0K7AxWkgKGvO8h52wVxHnfPUR3b4t6yNszoEFA4cVc7J J/T69WKejC6Lc8TtdP3Sk5IQwg1kemRQPpV6j0wF0GgA23uGa93aAHRpO3g0bmRBhIAZ TmXg== X-Gm-Message-State: APjAAAWmglvrhJ/99T9ckwMbJpoQ2JwBVtfbbYBHGXlRyzkYvpcmXKw2 ndXThpKDqcghmQqgfiME+HTAXejFGjbVDmoLX1Yi8w== X-Google-Smtp-Source: APXvYqwZiMpgZzy+yuafPgZayF/9Mj7jeo1b07E30d6W47pDXbXC8agbkEZYE59/TE9Agv/fJjmrpMn/ogrGJchf0a8= X-Received: by 2002:a67:ea02:: with SMTP id g2mr17657236vso.141.1553592552757; Tue, 26 Mar 2019 02:29:12 -0700 (PDT) MIME-Version: 1.0 References: <1552576396-19906-1-git-send-email-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Tue, 26 Mar 2019 10:29:01 +0100 Message-ID: To: Ferruh Yigit , Thomas Monjalon , Andrew Rybchenko Cc: dev , "Stokes, Ian" , Stephen Hemminger Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190326092901.515dcLcAMTpE0CON567Ur3p96NcvZP4g-oWn9_xcu2A@z> On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit wrote: > On 3/14/2019 3:13 PM, David Marchand wrote: > > Introduce a new api to retrieve per queue statistics from the drivers. > > The api objectives: > > - easily add some common per queue statistics and have it exposed > > through the user xstats api while the user stats api is left untouched > > - remove the limitations on the per queue statistics count (inherited > > from ixgbe) and avoid recurrent bugs on stats array overflow > > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my > concern is if it is overkill to have three dev_ops to get stats > and I am feeling that is making xstat code more complex. > Having these new (meant to be) internal dev_ops has the avantage of separating the statistics reported from the drivers from the exported api. This is also why I did not prefix the structure names with rte_. The "complex" part is in a single place, ethdev and this is when translating from an internal representation to the exposed bits in the public apis. Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct > rte_eth_stats'? > It does not solve the problem of drivers that are buggy because of the limit on RTE_ETHDEV_QUEUE_STAT_CNTRS. All drivers need to be aware of this limitation of the rte_eth_stats structure. The drivers manipulate queues in rx/tx_queue_setup dev_ops for example, having rxq/txq_stats_get dev_ops is more consistent to me. > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this > change, so > fix can be done with less changes, although it will push the fix into next > release because of the ABI break. > I am fine with merging this together, we don't want to backport this anyway, right? But so far, I don't feel the need to break the rte_eth_stats_get API, if we want to go to this, we can define an entirely new api to expose standardized bits and still use the rxq/txq_stats_get internal dev_ops I propose. Thomas, Andrew, can you provide feedback please ? rc1 is coming. -- David Marchand