From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 86D2E2951 for ; Tue, 16 Jan 2018 12:56:29 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 03:56:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,368,1511856000"; d="scan'208";a="10502838" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga008.jf.intel.com with ESMTP; 16 Jan 2018 03:56:26 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by IRSMSX151.ger.corp.intel.com ([169.254.4.108]) with mapi id 14.03.0319.002; Tue, 16 Jan 2018 11:56:26 +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+AIAADGEAgAT3+wCAAVSnUA== Date: Tue, 16 Jan 2018 11:56:25 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BAFE7F2@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> <3EB4FA525960D640B5BDFFD6A3D891267BAFC25A@IRSMSX108.ger.corp.intel.com> <3EB4FA525960D640B5BDFFD6A3D891267BAFC364@IRSMSX108.ger.corp.intel.com> <3F9268EEC0E43747A5FFFC6B48EF0321FC1018@gbcdcmbx03.intl.att.com> In-Reply-To: <3F9268EEC0E43747A5FFFC6B48EF0321FC1018@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.181] 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: Tue, 16 Jan 2018 11:56:29 -0000 > > > 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 already created are not impacted (they continue to work)? > > > > > > If the answer is 2, then yes, we could simply drop the > > > __rte_red_reset() and do the RED globals reset as part of the > > > rte_red_set_scaling() function transparently. > > > > > > 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 called at init time before any red objects are created. > > > > > > I probably need to spend more time assessing all the code implication= s. > > > > > > Regards, > > > Cristian > > > > Hi Alan, > > > > After talking to Tomasz, we agreed that 2. Is not an option, as any > previously created red object will be broken. > > > > So 1. Is the right answer, therefore this function can be called only o= nce > and only before any red objects are created. So, IMO we should do this: > -when rte_red_init_done is true, we need to return error -when > rte_red_init_done is false, we need to perform red initialization and set= this > flag > > > > Agree? >=20 > Yes, as long as you're happy with keeping __rte_red_reset for the unit-te= sts. >=20 OK