From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id B54183250 for ; Fri, 12 Jan 2018 12:09:23 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2018 03:09:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,348,1511856000"; d="scan'208";a="10697635" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga006.jf.intel.com with ESMTP; 12 Jan 2018 03:09:21 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by IRSMSX104.ger.corp.intel.com ([163.33.3.159]) with mapi id 14.03.0319.002; Fri, 12 Jan 2018 11:09:20 +0000 From: "Dumitrescu, Cristian" To: "Dewar, Alan" , "'alangordondewar@gmail.com'" CC: "'dev@dpdk.org'" , 'Alan Dewar' , "Kantecki, Tomasz" , "Singh, Jasvinder" Thread-Topic: [PATCH v5] sched: make RED scaling configurable Thread-Index: AQHTiJU2ELlQTwI26UWIYEeOEuz1fKNuoCmwgAFgwwCAABa+AA== Date: Fri, 12 Jan 2018 11:09:19 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BAFC25A@IRSMSX108.ger.corp.intel.com> References: <1507022514-21831-1> <1515425232-18888-1-git-send-email-alan.dewar@att.com> <3EB4FA525960D640B5BDFFD6A3D891267BAFB4EE@IRSMSX108.ger.corp.intel.com> <3F9268EEC0E43747A5FFFC6B48EF0321FC0CAF@gbcdcmbx03.intl.att.com> In-Reply-To: <3F9268EEC0E43747A5FFFC6B48EF0321FC0CAF@gbcdcmbx03.intl.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v5] sched: make RED scaling configurable 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: Fri, 12 Jan 2018 11:09:24 -0000 ... =20 > > > diff --git a/lib/librte_sched/rte_red.c b/lib/librte_sched/rte_red.c > > > +int > > > +rte_red_set_scaling(uint16_t max_red_queue_length) { > > > + int8_t count; > > > + > > > + if (rte_red_init_done) > > > + /** > > > + * Can't change the scaling once the red table has been > > > + * computed. > > > + */ > > > + return -1; > > > > Is there a reason why we cannot simply reset the scaling here? >=20 > Actually we could, but I was originally thinking that you might be happie= r > keeping with a one-time RED initialization function, but then had to > introduce the rte_reset_red_scaling function for the unit-tests. I'm happ= y to > do RED reinitialization here, if you are. >=20 Hi Alan, What is the intention of the new rte_red_set_scaling() function? 1. Is it to be called only once, before any RED object gets created? 2. Is it possible to call it post-init, but in this case any RED object al= ready created are not impacted (they continue to work)? If the answer is 2, then yes, we could simply drop the __rte_red_reset() an= d do the RED globals reset as part of the rte_red_set_scaling() function tr= ansparently. If the answer is 1, then we probably need to keep your approach: we need a = global rte_red_init_done flag, and rte_red_set_scaling() could only be call= ed at init time before any red objects are created. I probably need to spend more time assessing all the code implications. Regards, Cristian