From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) by dpdk.org (Postfix) with ESMTP id 8CF27D4F4 for ; Fri, 11 Nov 2016 10:16:30 +0100 (CET) Received: by mail-ua0-f180.google.com with SMTP id 12so8723464uas.2 for ; Fri, 11 Nov 2016 01:16:30 -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/zWZmuwOjxNqJBJHlooUWcImquzaryCwRTq9vKJpSw=; b=wcs67RxRZYSciUTjWGAz2NqZWj5SrJi/5hnudBEkstnLP4dnX4w7iedl41BB1lg7YL 6lroAGGLLuZXl5+0Pi51q8Psh8Iwzw+940+Ig3F/aS6dLL8TjuZCe8M0m8i/6f2oS/A1 lay6HK39GiSpp55SM3fFCiIsP1Wx5WQPdUbsRV1qHuko4HqN5Qdql2y0JDiIhOBCMbUX gAUko2yGfkPh84AWcGMMxzziUjPlsxh7xj/cbqNpAxfeqA0DVw4vG4B3hDQS/6yf5vzd ZTYXwL+8uyi1yeiiZFzGxYsbgRjs05i9RLxRkLKizR4RGDY93x6If7ySkRZ0fFveLtXx N31w== 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/zWZmuwOjxNqJBJHlooUWcImquzaryCwRTq9vKJpSw=; b=K+uzrYvDmxVGZwQW4t54PWYXyEoJsdmIwaW8tPmbkDA2FDKoYqQwhbyQu0nuNiEOsl 2EkxTMsNC7272aQ6BR0WvdJKm8drZq/bAz9GuTYDgK5uXWiSqve3/kCUK2aYV7OGMtdt l8JxpzJrb8NzqMbe0yNetu3hvNGEFO5MQ9cti2StSxSXtq3ckATpexDwG9qEFFF5wJhy rlTTyQcd4CROeKj22oSyiJThc2BqmGJzcQpUcs62Zy19C6kwcO4AN3WxlylkxPBgoEym Q9vHKKuS9hJTfHS7qzw8bBRox4JsDrjT24Qotv7miVKzBFtQ/cB0KWjySQ6MlXRBnPDY fPAA== X-Gm-Message-State: ABUngveZhq7mrDM4DW2033Q0ig7o28AlJiftDgdOWUYsdEe8enElaYGpdpn0vpCYeE+nnjHoQUPN/t2E/cSHg7Hk X-Received: by 10.159.48.65 with SMTP id i1mr1168943uab.12.1478855789915; Fri, 11 Nov 2016 01:16:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.79.145 with HTTP; Fri, 11 Nov 2016 01:16:29 -0800 (PST) In-Reply-To: References: <1478786449-44745-1-git-send-email-alejandro.lucero@netronome.com> <3059112.zVgrzqmBCq@xps13> <14529976.iPBWLuWW87@xps13> From: Alejandro Lucero Date: Fri, 11 Nov 2016 09:16:29 +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: Fri, 11 Nov 2016 09:16:31 -0000 Thomas, We are wondering if you realize this patch fixes a bug with current ethdev code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS. Maybe the commit message is giving the wrong impression and as you commented, it should just focus on the bug it fixes and to leave for another email thread the discussion of how to solve the RTE_ETHDEV_QUEUE_STAT_CNTRS problem. Should we remove this from patchwork and to send another patch that way? On Thu, Nov 10, 2016 at 4:04 PM, Alejandro Lucero < alejandro.lucero@netronome.com> wrote: > > > On Thu, Nov 10, 2016 at 4:01 PM, Thomas Monjalon < > thomas.monjalon@6wind.com> 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 >