From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 284B4B347 for ; Fri, 19 Sep 2014 11:12:42 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 19 Sep 2014 02:18:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,554,1406617200"; d="scan'208";a="593737407" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 19 Sep 2014 02:18:28 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.112]) by IRSMSX101.ger.corp.intel.com ([169.254.1.194]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 10:18:27 +0100 From: "Richardson, Bruce" To: Neil Horman , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH 3/5] testpmd: Change rxfreet default to 32 Thread-Index: AQHP0l5oUFb5FU7UokiprGez8jDZ8pwFYuqAgAASbWCAAZz/AIAAD1GAgAEJxXA= Date: Fri, 19 Sep 2014 09:18:26 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B0343F38AD@IRSMSX103.ger.corp.intel.com> References: <1410948102-12740-1-git-send-email-bruce.richardson@intel.com> <20140917152945.GF4213@localhost.localdomain> <59AF69C657FD0841A61C55336867B5B0343F355F@IRSMSX103.ger.corp.intel.com> <3289751.t83Qqk3rkH@xps13> <20140918180841.GN20389@hmsreliant.think-freely.org> In-Reply-To: <20140918180841.GN20389@hmsreliant.think-freely.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 3/5] testpmd: Change rxfreet default to 32 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, 19 Sep 2014 09:12:43 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Thursday, September 18, 2014 7:09 PM > To: Thomas Monjalon > Cc: Richardson, Bruce; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 3/5] testpmd: Change rxfreet default to 32 >=20 > On Thu, Sep 18, 2014 at 07:13:52PM +0200, Thomas Monjalon wrote: > > 2014-09-18 15:53, Richardson, Bruce: > > > > > --- a/app/test-pmd/testpmd.c > > > > > +++ b/app/test-pmd/testpmd.c > > > > > @@ -225,7 +225,7 @@ struct rte_eth_thresh tx_thresh =3D { > > > > > /* > > > > > * Configurable value of RX free threshold. > > > > > */ > > > > > -uint16_t rx_free_thresh =3D 0; /* Immediately free RX descriptor= s by > default. */ > > > > > +uint16_t rx_free_thresh =3D 32; /* Refill RX descriptors once ev= ery 32 > packets > > > > */ > > > > > > > > > > > > > Why 32? Was that an experimentally determined value? > > > > Does it hold true for all PMD's? > > > > > > This is primarily for the ixgbe PMD, which is right now the most > > > highly tuned driver, but it works fine for all other ones too, > > > as far as I'm aware. > > > > Yes, you are changing this value for all PMDs but you're targetting > > only one. > > These thresholds are dependent of the PMD implementation. There's > > something wrong here. > > > I agree. Its fine to do this, but it does seem like the sample applicatio= n > should document why it does this and make note of the fact that other PMD= s > may > have a separate optimal value. >=20 > > > Basically, this is the minimum setting needed to enable either the > > > bulk alloc or vector RX routines inside the ixgbe driver, so it's > > > best made the default for that reason. Please see > > > "check_rx_burst_bulk_alloc_preconditions()" in ixgbe_rxtx.c, and > > > RX function assignment logic in "ixgbe_dev_rx_queue_setup()" in > > > the same file. > > > > Since this parameter is so important, it could be a default value somew= here. > > > > I think we should split generic tuning parameters and tuning parameters > > related to driver implementation or specific hardware. > > Then we should provide some good default values for each of them. > > At last, if needed, applications should be able to easily tune the > > pmd-specific parameters. > > > I like this idea. I've not got an idea of how much work it is to do so, = but in > principle it makes sense. >=20 > Perhaps for the immediate need, since rte_eth_rx_queue_setup allows the > config > struct to get passed directly to PMDs, we can create a reserved value > RTE_ETH_RX_FREE_THRESH_OPTIMAL, that instructs the pmd to select > whatever > threshold is optimal for its own hardware? >=20 > Neil >=20 Actually, looking at the code, I would suggest a couple of options, some of= which may be used together. 1) we make NULL a valid value for the rxconf structure parameter to rte_et= h_rx_queue_setup. There is little information in it that should really need= to be passed in by applications to the drivers, and that would allow the d= rivers to be completely free to select the best options for their own opera= tion.=20 2) As a companion to that (or as an alternative), we could also allow each= driver to provide its own functions for rte_eth_get_rxconf_default, and rt= e_eth_get_txconf_default, to be used by applications that want to use known= -good values for thresholds but also want to tweak one of the other values = e.g. for rx, set the drop_en bit, and for tx set the txqflags to disable of= floads. 3) Lastly, we could also consider removing the threshold and other not-gen= erally-used values from the rxconf and txconf structures and make those rem= oved fields completely driver-set values. Optionally, we could provide an a= lternate API to tune them, but I don't really see this being useful in most= cases, and I'd probably omit it unless someone can prove a need for such A= PIs. Regards, /Bruce