From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 716775A84 for ; Mon, 16 Mar 2015 20:58:55 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 16 Mar 2015 12:53:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,411,1422950400"; d="scan'208";a="699522432" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga002.jf.intel.com with ESMTP; 16 Mar 2015 12:58:53 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.218]) by IRSMSX104.ger.corp.intel.com ([169.254.5.145]) with mapi id 14.03.0195.001; Mon, 16 Mar 2015 19:58:52 +0000 From: "Dumitrescu, Cristian" To: Stephen Hemminger Thread-Topic: [PATCH v2 5/6] rte_sched: allow reading statistics without clearing Thread-Index: AQHQW01BWBc5LZFsfEaJqAZ+MDSn9J0ZObsggABB/wCABhBNcA== Date: Mon, 16 Mar 2015 19:58:51 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912632323539@IRSMSX108.ger.corp.intel.com> References: <1426004018-25948-1-git-send-email-stephen@networkplumber.org> <1426004018-25948-6-git-send-email-stephen@networkplumber.org> <3EB4FA525960D640B5BDFFD6A3D89126323225F4@IRSMSX108.ger.corp.intel.com> <20150312160626.47315f49@urahara> In-Reply-To: <20150312160626.47315f49@urahara> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , Stephen Hemminger Subject: Re: [dpdk-dev] [PATCH v2 5/6] rte_sched: allow reading statistics without clearing 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: Mon, 16 Mar 2015 19:58:56 -0000 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Thursday, March 12, 2015 11:06 PM > To: Dumitrescu, Cristian > Cc: dev@dpdk.org; Stephen Hemminger > Subject: Re: [PATCH v2 5/6] rte_sched: allow reading statistics without > clearing >=20 > On Thu, 12 Mar 2015 19:28:11 +0000 > "Dumitrescu, Cristian" wrote: >=20 > > Hi Stephen, > > > > Thank you for adding flexibility over clearing the stats or not. > > > > I have one concern though: why change the stats read API to add a clear > parameter rather than keep prototype for the stats functions unchanged an= d > add the flag as part of the port creation parameters in struct > rte_sched_port_params? This parameter could be saved into the internal > struct rte_sched_port, which is passed (as a pointer) to the stats read > functions. In my opinion, this approach is slightly more elegant and it k= eeps > the changes to a minimum. > > > > int > > rte_sched_queue_read_stats(struct rte_sched_port *port, > > uint32_t queue_id, > > struct rte_sched_queue_stats *stats, > > uint16_t *qlen) > > { > > ... > > if (port->clear_stats_on_read) > > memset(...); > > } > > > > I made this suggestion during the previous round, but I did not get any > opinion from you on it yet. > > > > Regards, > > Cristian >=20 > I rejected the config parameter idea because I don't like it is inconsist= ent > with other statistics in DPDK and in related software. There is not a > config parameter that changes what BSD or Linux kernel API does. Your approach has the advantage of being able to clear/not clear the stats = per each read operation rather than configuring the behavior globally. I th= ink this approach allows for the ultimate flexibility, so I am OK to go wit= h it. >=20 > The only reason for keeping the read and clear in one operation is > because you like it, and there are somebody might have built code > that expects it. > Clearing the stats with a delay after the stats have been read is prone to = a race condition, as during this time more packets could be processed, and = these packets will not show up in the counters that the user read. I think it depends on the need of each particular application whether this = race condition is important or not: if the counters are read rarely (e.g. o= nce per day) and only course accuracy is required, the error is probably ir= relevant; if the app is looking for fine great accuracy (e.g. rate measurem= ent, debugging, etc), then the error is not allowed. You seem to favour the= former and ignore the later case. > Changing the function signature is a nice red flag so that people will > notice at change. There is a small API change here. I am OK with it for the above reasons, pr= ovided that there are no objections on this from other contributors.