From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by dpdk.org (Postfix) with ESMTP id 25A7F567A for ; Thu, 1 Dec 2016 15:44:46 +0100 (CET) Received: by mail-vk0-f53.google.com with SMTP id w194so129397867vkw.2 for ; Thu, 01 Dec 2016 06:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V+wp5flGr3YxML0F2HseivnJ/8qUgctFzWX9UppdmkM=; b=v+OfCXyq560ZqSfaVXOGJsQ2yTOGDFbdXN7nIc8eGKSDus59ioNnnAShneqCc7rSc1 tCacqUOUcZaZhar7rRGh8Glo0vp+3ky0OFOMcx7r89uNrhok0v3km6A/nCWNY15sGVsH vrQ+hqshGsNb3w3PbdMmCPc63/SnjSBkTYYo+plHoeIjxdpDMR6zQndTQobfmn00LWqb cR8ew62eDFy7kFErFQoSOinM8/q6wkg0cuRSPhDskpJB9ygyKLEW/Q5e5vwc4U5ckzEB lKwLBwqeZPHg6qUGFIQLAsig85bGVeyMesBWDGVcumkM6u8PxQDNVDEzkblJ3ukz+fJr hS+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V+wp5flGr3YxML0F2HseivnJ/8qUgctFzWX9UppdmkM=; b=NlfMFX0RgSEdsujZL1dyOTDBf4MVm8TLHvZb3XsUqPF9/fJ9x9QtMVB3Ph2OB7jcyR OxtRrEq4fvlBo0EGsBEpUIdNH+w4cRGBOMvbjpHf1X65/o+4KVNS4iUl9SGOOzw+5Qil +VOILjHtsrxKQcWu4vqG3sOMIpzgJm9EeqExnpcL9tELQ8D2yVtVpYAt95IQun7axotz A0lF1duafaRcGM7RiCwxqdnFYZIh0LpjA/qQWoztdAGosy0N0fIHQKKAGllNFurwVrch Zq87mAK0v60WwcUAItzOxS14X91SVK4yt26WrVcCXC13EqahjjSRJmGC21onD8+vcVtz /S7A== X-Gm-Message-State: AKaTC03gljl4GjtHrGh8lATQrJ+TMSXgYDvP2xcBr7/0nKVuvb+vt3ST+OOxHWjUEBcHbr82LUXIgICg1Psm/I/4 X-Received: by 10.31.234.199 with SMTP id i190mr14140242vkh.31.1480603486446; Thu, 01 Dec 2016 06:44:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.46.3 with HTTP; Thu, 1 Dec 2016 06:44:45 -0800 (PST) In-Reply-To: <7874818.0HvcekTQN4@xps13> References: <1479722378-23959-1-git-send-email-alejandro.lucero@netronome.com> <1480006746.31853.14.camel@6wind.com> <7874818.0HvcekTQN4@xps13> From: Alejandro Lucero Date: Thu, 1 Dec 2016 14:44:45 +0000 Message-ID: To: Thomas Monjalon Cc: Olivier Matz , dev , Bert van Leeuwen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 14:44:47 -0000 On Mon, Nov 28, 2016 at 11:13 AM, Thomas Monjalon wrote: > 2016-11-24 17:59, Olivier Matz: > > Hi, > > > > On Mon, 2016-11-21 at 09:59 +0000, Alejandro Lucero wrote: > > > From: Bert van Leeuwen > > > > > > Arrays inside rte_eth_stats have size=RTE_ETHDEV_QUEUE_STAT_CNTRS. > > > Some devices report more queues than that and this code blindly uses > > > the reported number of queues by the device to fill those arrays up. > > > This patch fixes the problem using MIN between the reported number of > > > queues and RTE_ETHDEV_QUEUE_STAT_CNTRS. > > > > > > Signed-off-by: Alejandro Lucero > > > > > > > Reviewed-by: Olivier Matz > > > > > > As a next step, I'm wondering if it would be possible to remove > > this limitation. We could replace the tables in struct rte_eth_stats > > by a pointer to an array allocated dynamically at pmd setup. > > Yes that's definitely the right way to handle these statistics. > > Agree. > > It would break the API, so it should be announced first. I'm thinking > > of something like: > > > > struct rte_eth_generic_stats { > > uint64_t ipackets; > > uint64_t opackets; > > uint64_t ibytes; > > uint64_t obytes; > > uint64_t imissed; > > uint64_t ierrors; > > uint64_t oerrors; > > uint64_t rx_nombuf > > }; > > > > struct rte_eth_stats { > > struct rte_eth_generic_stats port_stats; > > struct rte_eth_generic_stats *queue_stats; > > }; > > > > The queue_stats array would always be indexed by queue_id. > > The xstats would continue to report the generic stats per-port and > > per-queue. > > > > About the mapping API, either we keep it as-is, or it could > > become a driver-specific API. > > Yes I agree to remove the queue statistics mapping which is very specific. > I will send a patch with a deprecation notice to move the mapping API > to a driver-specific API. > > Any objection? > No from my side.