From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com [209.85.217.174]) by dpdk.org (Postfix) with ESMTP id 3612C6CB3 for ; Thu, 10 Nov 2016 17:04:59 +0100 (CET) Received: by mail-ua0-f174.google.com with SMTP id 20so204650039uak.0 for ; Thu, 10 Nov 2016 08:04:59 -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=WLAdQ66x8kO/evEPziTLrOl+e7g7Qs3XhrIKHzI7KSk=; b=nHZwR8+j+xXGHP3mDFFG8TFWYVprORrr7DXYaYo0rfBTR03f0kS9Gc11QydeskzEJ6 jfkzzwxtH0QX2btTSM1RdzD0EW9WA3aXZ8Um/BXR+5dUvogOGTOaAWPJk00lpDAzXpxS VqHu1oKeip+9rp9xhOuGxBZVWDRA0g39AynkhcPXgsBIFyL7WISkbu3xLuCRmH2zigN4 q5fqcvGm/vqaKAXivhhXR2XsLEvhnPdMVPBaYU9vrFv0q/O0DRsoomY54fctLSLEPEHN 77ytWi1wmKK6y+1gYA+VCQSFXq3qXF3cufjdxB3cQ3EKPdPOkHa8XUQYcW8QObWLskSt rw+g== 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=WLAdQ66x8kO/evEPziTLrOl+e7g7Qs3XhrIKHzI7KSk=; b=SEwIJkVAaHpaR3pF1YP+/w4oymAtJl4VKnEzYW1R52Lllhof3yuC113sh3SswtHA0n TWUGZtZj94OnmRZi1Lqc+5C3EHo0vjxparIPZXL1OJ4B279K1LFOQ+Y0Yytzv6U0JhZ0 6c8PSW0jjFOjnm3yHxG3HKD6t1aBOGObMY09aiNH/SGwlBKRl19uNG7QZJiMNlPHElB5 T+37lQ1ds32hnuKvV78oIh2aw2E9Z+zM8OtH2KdcAnJfICkWGitbhZM9dt4pwNm114ew s5OXPlXR5dqaHjCVobUkZ6o323kWtLvDVN9/HGhjqSAR6oCDq9X1JNymU3V2rbfAgcho MTzw== X-Gm-Message-State: ABUngvfl5Dd06Q+lVVxww41Hw7cA0y5B4Qt8ryXxocmOv1W5Keu0zq3Tyko3V3ijS+15pBTL2vkfY1WV5d3MR6Rw X-Received: by 10.176.71.134 with SMTP id v6mr959465uac.174.1478793898684; Thu, 10 Nov 2016 08:04:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.79.145 with HTTP; Thu, 10 Nov 2016 08:04:58 -0800 (PST) In-Reply-To: <14529976.iPBWLuWW87@xps13> References: <1478786449-44745-1-git-send-email-alejandro.lucero@netronome.com> <3059112.zVgrzqmBCq@xps13> <14529976.iPBWLuWW87@xps13> From: Alejandro Lucero Date: Thu, 10 Nov 2016 16:04:58 +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 16:04:59 -0000 On Thu, Nov 10, 2016 at 4:01 PM, Thomas Monjalon wrote: > 2016-11-10 15:43, Alejandro Lucero: > > On Thu, Nov 10, 2016 at 2:42 PM, Thomas Monjalon < > thomas.monjalon@6wind.com> > > 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? > > I think this patch is doing something else :) > > Sure. But the problem the patch solves is pointing to this, IMHO, bigger issue. > I'm not sure what is better between big arrays and variable size. > I think you must explain these 2 options in another thread, > because I'm not sure you will have enough attention in a thread starting > with > "check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS". > Agree. I'll do that then. Thanks