From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id C47751B3B4; Tue, 10 Jul 2018 09:06:55 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 43645100059; Tue, 10 Jul 2018 07:06:51 +0000 (UTC) Received: from [192.168.1.16] (85.187.13.33) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 10 Jul 2018 08:06:43 +0100 To: Jerin Jacob , Ferruh Yigit CC: Andrew Rybchenko , , , References: <20180629094443.26540-1-jerin.jacob@caviumnetworks.com> <22d74419-6842-044c-9c61-7855925bf41b@intel.com> <47d3c4aa-04f7-110b-f889-cfb07fecdfca@solarflare.com> <20180710062023.GA2600@jerin> From: Andrew Rybchenko Message-ID: <799fe61d-4895-fd84-3d53-862feb1d9ea4@solarflare.com> Date: Tue, 10 Jul 2018 10:06:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180710062023.GA2600@jerin> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [85.187.13.33] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23958.003 X-TM-AS-Result: No--28.084500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1531206412-JEbV3W6E_Sim Subject: Re: [dpdk-dev] [PATCH] ethdev: fix queue mapping documentation 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: , X-List-Received-Date: Tue, 10 Jul 2018 07:06:56 -0000 On 10.07.2018 09:20, Jerin Jacob wrote: > -----Original Message----- >> Date: Mon, 2 Jul 2018 16:45:33 +0100 >> From: Ferruh Yigit >> To: Andrew Rybchenko , Jerin Jacob >> , dev@dpdk.org >> CC: thomas@monjalon.net, stable@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] ethdev: fix queue mapping documentation >> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 >> Thunderbird/52.8.0 >> >> >> On 7/2/2018 4:32 PM, Andrew Rybchenko wrote: >>> On 07/02/2018 06:08 PM, Ferruh Yigit wrote: >>>> On 6/29/2018 10:44 AM, Jerin Jacob wrote: >>>>> The RTE_MAX_ETHPORT_QUEUE_STATS_MAPS does not exists, change >>>>> to the correct definition(RTE_ETHDEV_QUEUE_STAT_CNTRS) >>>>> >>>>> Fixes: 5de201df8927 ("ethdev: add stats per queue") >>>>> Cc: stable@dpdk.org >>>>> >>>>> Signed-off-by: Jerin Jacob >>>>> --- >>>>> lib/librte_ethdev/rte_ethdev.h | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h >>>>> index 36e3984ea..375ea24ce 100644 >>>>> --- a/lib/librte_ethdev/rte_ethdev.h >>>>> +++ b/lib/librte_ethdev/rte_ethdev.h >>>>> @@ -2144,7 +2144,7 @@ void rte_eth_xstats_reset(uint16_t port_id); >>>>> * @param stat_idx >>>>> * The per-queue packet statistics functionality number that the transmit >>>>> * queue is to be assigned. >>>>> - * The value must be in the range [0, RTE_MAX_ETHPORT_QUEUE_STATS_MAPS - 1]. >>>>> + * The value must be in the range [0, RTE_ETHDEV_QUEUE_STAT_CNTRS - 1]. >>>> Yes RTE_MAX_ETHPORT_QUEUE_STATS_MAPS doesn't exits and comment is wrong, but >>>> RTE_ETHDEV_QUEUE_STAT_CNTRS also slightly not correct. >>>> >>>> I think how testpmd uses it increase the confusion. >>>> >>>> In ixgbe there is no stats registers per queue, 128 queues are represented by 16 >>>> register set. stat_idx here is the index of that 16 registers. You map queue to >>>> stats requester to get queue stats. >>>> >>>> Also there is RTE_ETHDEV_QUEUE_STAT_CNTRS config in the ethdev API, which is the >>>> hardcoded size of the queue stats, its default value is 16. This limits number >>>> of the queues we can get stats from but saves allocated space. (Why not dynamic?) >>>> >>>> You can increase the RTE_ETHDEV_QUEUE_STAT_CNTRS to the max supported number of >>>> queue and ethdev code will be all valid. But "stat_idx" can't go beyond 16 (for >>>> ixgbe) because it is hardware limitation and it may change from hw to hw. >>>> >>>> Also technically it should be possible to reduce RTE_ETHDEV_QUEUE_STAT_CNTRS to >>>> a low number, like 2, but in ixgbe map two queues into stat registers 14 & 15 >>>> and display those two set as queue stat 0 and 1. It seems current implementation >>>> prevents this and forces the queues mapped should be less than >>>> RTE_ETHDEV_QUEUE_STAT_CNTRS. Overall it seems there is a mixed used of >>>> RTE_ETHDEV_QUEUE_STAT_CNTRS and stats queue index values, I assume because both >>>> are same values. >>>> >>>> I suggest updating it as: >>>> " >>>> The value must be in the range: >>>> [0 - MIN(HW Stat Registers Size, RTE_ETHDEV_QUEUE_STAT_CNTRS) - 1] >>>> " >>> Technically I think it is not a problem to specify more than HW supports. >>> The function should simply return error. RTE_ETHDEV_QUEUE_STAT_CNTRS is >>> a hard limit which should be checked by ethdev. >>> The reasonable next question is how to find out what is the maximum for PMD/HW. >>> I think it deserves entry in dev_info. May be not now. >> Yes there is not a way to find out that limit by application, setting >> RTE_ETHDEV_QUEUE_STAT_CNTRS to 16 and using it as limit solving the issue for now :) > > If I understand it correctly, in the documentation, we are specify the > limits to avoid the segfault etc and if the specific PMD does not > support the range up to RTE_ETHDEV_QUEUE_STAT_CNTRS, It can simply return > error which makes the documentation semantically correct. > > Considering the above point, I think this patch is correct considering > there is no way currently to detect the limit supported by PMD. So, > 1) Should we keep the patch as is? > > -- > The value must be in the range [0, RTE_ETHDEV_QUEUE_STAT_CNTRS - 1]. > -- > > OR > > 2) Change to > > -- > The value must be in the range: > [0 - MIN(Device max per Tx queue stats, RTE_ETHDEV_QUEUE_STAT_CNTRS) - 1] > -- > > I prefer option 1. But I am okay send v2 if any ethdev maintainers prefer > option 2. > > Let me know. I would prefer option 1 as well since right now we have no way to advertise/find out "Device max per Tx queue stats". Andrew.