From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 968BE5948 for ; Wed, 22 Oct 2014 00:35:32 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 21 Oct 2014 15:42:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,765,1406617200"; d="scan'208";a="622816082" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga002.jf.intel.com with ESMTP; 21 Oct 2014 15:43:47 -0700 Received: from irsmsx107.ger.corp.intel.com (163.33.3.99) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 21 Oct 2014 23:43:47 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.174]) by IRSMSX107.ger.corp.intel.com ([169.254.10.68]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 23:43:46 +0100 From: "Ananyev, Konstantin" To: Neil Horman , "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx cycles/packet Thread-Index: AQHP5LMIlpl/13ytTkee3VaYZ7hCTJwsQCWAgA4aiICAAAK9gIAAMMgAgACnb5A= Date: Tue, 21 Oct 2014 22:43:45 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772582139510A@IRSMSX105.ger.corp.intel.com> References: <1408947174-11323-1-git-send-email-cunming.liang@intel.com> <1412944201-30703-1-git-send-email-cunming.liang@intel.com> <1412944201-30703-2-git-send-email-cunming.liang@intel.com> <20141010175226.GG19499@hmsreliant.think-freely.org> <20141021103315.GB12795@hmsreliant.think-freely.org> <59AF69C657FD0841A61C55336867B5B0344212BF@IRSMSX103.ger.corp.intel.com> <20141021133738.GC12795@hmsreliant.think-freely.org> In-Reply-To: <20141021133738.GC12795@hmsreliant.think-freely.org> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] 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 v2 1/4] app/test: unit test for rx and tx cycles/packet 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: Tue, 21 Oct 2014 22:35:33 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman > Sent: Tuesday, October 21, 2014 2:38 PM > To: Richardson, Bruce > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and tx = cycles/packet >=20 > On Tue, Oct 21, 2014 at 10:43:03AM +0000, Richardson, Bruce wrote: > > > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman > > > Sent: Tuesday, October 21, 2014 11:33 AM > > > To: Liang, Cunming > > > Cc: dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] app/test: unit test for rx and= tx > > > cycles/packet > > > > > > > > > > > > > > + if (count =3D=3D 0) > > > > > > + return -1; > > > > > > + > > > > > > + printf("%lu packet, %lu drop, %lu idle\n", count, drop, idle)= ; > > > > > > + printf("Result: %ld cycles per packet\n", (cur_tsc - prev_tsc= ) / count); > > > > > > + > > > > > Bad math here. Theres no guarantee that the tsc hasn't wrapped (= potentially > > > > > more than once) depending on your test length. you need to check= the tsc > > > before > > > > > and after each burst and record an average of deltas instead, acc= ounting in > > > each > > > > > instance for the possibility of wrap. > > > > [Liang, Cunming] I'm not sure catch your point correctly. > > > > I think both cur_tsc and prev_tsc are 64 bits width. > > > > For 3GHz, I think it won't wrapped so quick. > > > > As it's uint64_t, so even get wrapped, the delta should still be co= rrect. > > > But theres no guarantee that the tsc starts at zero when you begin yo= ur test. > > > The system may have been up for a long time and near wrapping already= . > > > Regardless, you need to account for the possibility that cur_tsc is s= maller > > > than prev_tsc, or this breaks. > > > > > > > The tsc. is 64-bit and so only wraps around every couple of hundred yea= rs or so on a 2GHz machine, so I don't think it's necessary to > handle that case. > > > But that presumes that no one has written the TSC via IA32_TIME_STAMP_COU= NTER. Then the test app would just print the wrong number :) I suppose user will just repeat the test. Again, imagine someone wrmsr(TSC), but set the value just much bigger than = current. Then your statistics will be incorrect, but you have no wait to figure that= out.=20 I think that trying to handle all such hypothetical situations is a pure ov= erkill. > Assuming that something will never wrap just seems like bad practice here= . We > should have a general purpose macro to handle wrapping counters like this= , if > not for this case specficially, then in general. >=20 > Neil >=20 > > /Bruce > >