From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com [209.85.217.179]) by dpdk.org (Postfix) with ESMTP id A2AC99E7 for ; Thu, 10 Nov 2016 16:43:09 +0100 (CET) Received: by mail-ua0-f179.google.com with SMTP id b35so203957828uaa.3 for ; Thu, 10 Nov 2016 07:43:09 -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=CyIt2Vsla3zevYn07+D5shB3TXw2Hrg0wSfAeUFPdFU=; b=vfOZ7lplDFaXlY57ndQT8wEgFLNbeuygL7AY+QmbCwdC5GGDtw/bPI82PPGQKCfWVd Z4Ik7ZqQ/0Z9Lsw9NnrUZAqNqYixPSgSZdKiC3Q/XIsE8IRYLP8Q1z361lEUuKHlRl4i qYMAg/GNOLuX5KSwqzI47kYLR8J/LUDBxRhKtkYKkAa7T2qt8ESHX3UPEbLvjFkUrQCi pUDfUUO0p2FT6/CPAU/0u4tirefKRX805ILGQAJp7rq03RQyWIZ+ygSJ7MI6elQak3yc KvPNjMnykwWnwVa/ySPpcJ4ssh7/LSaUVdJrCLu5NmSLrCGNhIJD7RiDXhLm8hP/6ZwQ RvUQ== 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=CyIt2Vsla3zevYn07+D5shB3TXw2Hrg0wSfAeUFPdFU=; b=abE2Klwocql4B5T962+anQzpqV2F8+ysuemCmRqENbVM3SJLbHqybNu7M/PuPW/47w doWeE63ZgZZXnfykkB6+nJpaMSzv2CcLJjMFZHrYG8pEnP/flWxxPuw86Os65BGHSo/K 8aqchMEXv+EFOGFs8mLASYWRkfAoY8NqTUXyeLe9uhEYrrpQsdcOMfeeDmvW1/l49v60 x+jDvc+xwBB9FeVaYdi2iSRCnXlcDzhI41S0wY1BcBFBf1QkBPdIN07BPwEhUEK15kRq fMTM/eXLQllxF50N6gqVuLpxujh0DPyJCWBSOc+hvHrtaWfKA/xNIgDRO4HhcI2ppDvu 20mA== X-Gm-Message-State: ABUngvcVRRfapngya3E0WtBPSLlPTvTwqggc1pDvs7GKaHbGtw8GI+JZh3+tBJ43uyAoID47AleNJNB5tGTvHSJ1 X-Received: by 10.159.48.65 with SMTP id i1mr3754903uab.12.1478792589034; Thu, 10 Nov 2016 07:43:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.79.145 with HTTP; Thu, 10 Nov 2016 07:43:08 -0800 (PST) In-Reply-To: <3059112.zVgrzqmBCq@xps13> References: <1478786449-44745-1-git-send-email-alejandro.lucero@netronome.com> <3059112.zVgrzqmBCq@xps13> From: Alejandro Lucero Date: Thu, 10 Nov 2016 15:43:08 +0000 Message-ID: To: Thomas Monjalon Cc: 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] 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, 10 Nov 2016 15:43:10 -0000 On Thu, Nov 10, 2016 at 2:42 PM, Thomas Monjalon wrote: > 2016-11-10 14:00, Alejandro Lucero: > > From: Bert van Leeuwen > > > > A device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS queues which > > is used inside struct rte_eth_stats. Ideally, DPDK should be built with > > RTE_ETHDEV_QUEUE_STAT_CNTRS to the maximum number of queues a device > > can support, 65536, as uint16_t is used for keeping those values for > > RX and TX. But of course, having such big arrays inside struct > rte_eth_stats > > is not a good idea. > > RTE_ETHDEV_QUEUE_STAT_CNTRS come from a limitation in Intel devices. > They have limited number of registers to store the stats per queue. > > > Current default value is 16, which could likely be changed to 32 or 64 > > without too much opposition. And maybe it would be a good idea to modify > > struct rte_eth_stats for allowing dynamically allocated arrays and maybe > > some extra fields for keeping the array sizes. > > Yes > and? what is your issue exactly? with which device? > Please explain the idea brought by your patch. > Netronome NFP devices support 128 queues and future version will support 1024. A particular VF, our PMD just supports VFs, could get as much as 128. Although that is not likely, that could be an option for some client. Clients want to use a DPDK coming with a distribution, so changing the RTE_ETHDEV_QUEUE_STAT_CNTRS depending on the present devices is not an option. We would be happy if RTE_ETHDEV_QUEUE_STAT_CNTRS could be set to 1024, covering current and future requirements for our cards, but maybe having such big arrays inside struct rte_eth_stats is something people do not want to have. A solution could be to create such arrays dynamically based on the device to get the stats from. For example, call to rte_eth_dev_configure could have ax extra field for allocating a rte_eth_stats struct, which will be based on nb_rx_q and nb_tx_q params already given to that function. Maybe the first thing to know is what people think about just incrementing RTE_ETHDEV_QUEUE_STAT_CNTRS to 1024. So Thomas, what do you think about this?