From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id E7F0B7CDB for ; Wed, 14 Jun 2017 12:37:48 +0200 (CEST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 68F5B80060; Wed, 14 Jun 2017 10:37:48 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us3.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id BA13C80052; Wed, 14 Jun 2017 10:37:47 +0000 (UTC) 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-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 4BE9960055; Wed, 14 Jun 2017 10:37:47 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 14 Jun 2017 11:37:36 +0100 To: Stephen Hemminger , Thomas Monjalon References: <1488459935-13273-2-git-send-email-arybchenko@solarflare.com> <1495727874-10892-1-git-send-email-arybchenko@solarflare.com> <20170525104033.43a6e02f@xeon-e3> CC: , Sergio Gonzalez Monroy , Remy Horton , Jianfeng Tan , Declan Doherty , Ferruh Yigit , Yuanhan Liu , "Maxime Coquelin" , Konstantin Ananyev , Bruce Richardson , Reshma Pattan , Cristian Dumitrescu , Byron Marohn , Pablo de Lara Guarch , Pawel Wodkowski , Tomasz Kantecki , John McNamara , Daniel Mrzyglod , Roman Zhukov From: Andrew Rybchenko Message-ID: Date: Wed, 14 Jun 2017 13:37:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170525104033.43a6e02f@xeon-e3> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [84.52.114.114] 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-23130.003 X-TM-AS-Result: No--8.405100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1497436668-qtUVaHweIlRw Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add function to adjust number of descriptors 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: Wed, 14 Jun 2017 10:37:49 -0000 On 05/25/2017 08:40 PM, Stephen Hemminger wrote: > On Thu, 25 May 2017 16:57:53 +0100 > Andrew Rybchenko wrote: > >> From: Roman Zhukov >> >> Check that numbers of Rx and Tx descriptors satisfy descriptors limits >> from the Ethernet device information, otherwise adjust them to boundaries. >> >> Signed-off-by: Roman Zhukov >> Signed-off-by: Andrew Rybchenko > Seems like new added complexity. It looks like there is no more comments. > Why not just allow devices to take the request as a hint and truncate or pad > as needed. Yes, it is possible solution. In this case rte_eth_rx_queue_info_get() may be used to get real values. If so, first of all it should be clearly documented in the rte_eth_rx_queue_setup()/rte_eth_tx_queue_setup() and rte_eth_rx_queue_info_get()/rte_eth_tx_queue_info_get(). However, the problem of such approach is non-obvious modification of values specified by the ethdev API caller. Some applications use ring sizes to estimate mbuf pool size and other resources and if real values differ from specified (and it is not taken into account since everything happens silently without any errors) it could be tricky to find out root cause of possible problems. That's why we have chosen approach with extra helper function which does the adjustment. > IMHO to be successful DPDK must have as simple as possible API for application. > Good enough and as little more as possible. But other people seem to think > that having the richest and most complex possible API is a good thing.