From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cristian.dumitrescu@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id 3EC3A5A0A
 for <dev@dpdk.org>; Thu, 21 May 2015 01:56:57 +0200 (CEST)
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
 by fmsmga101.fm.intel.com with ESMTP; 20 May 2015 16:56:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.13,466,1427785200"; d="scan'208";a="729315033"
Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25])
 by fmsmga002.fm.intel.com with ESMTP; 20 May 2015 16:56:53 -0700
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.59]) by
 irsmsx110.ger.corp.intel.com ([163.33.3.25]) with mapi id 14.03.0224.002;
 Thu, 21 May 2015 00:56:52 +0100
From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>, Stephen Hemminger
 <stephen@networkplumber.org>
Thread-Topic: [dpdk-dev] [PATCH v2] pipeline: add statistics for
 librte_pipeline	ports and tables
Thread-Index: AQHQkWZQUPiGW1BlN0muPEnhvuILX52D/wVsgADlY3D///8CgIAANokAgABDp4CAACzawA==
Date: Wed, 20 May 2015 23:56:52 +0000
Message-ID: <3EB4FA525960D640B5BDFFD6A3D891263236A970@IRSMSX108.ger.corp.intel.com>
References: <1430396143-10936-1-git-send-email-michalx.k.jastrzebski@intel.com>
 <2017641.P0ts6fjbPO@xps13> <20150520105946.4ac86349@uryu.home.lan>
 <1870211.3M6CNgV6Ua@xps13>
In-Reply-To: <1870211.3M6CNgV6Ua@xps13>
Accept-Language: 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" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] pipeline: add statistics for
 librte_pipeline	ports and tables
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2015 23:56:58 -0000



> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, May 20, 2015 11:02 PM
> To: Stephen Hemminger; Dumitrescu, Cristian
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] pipeline: add statistics for librte_pi=
peline
> ports and tables
>=20
> 2015-05-20 10:59, Stephen Hemminger:
> > On Wed, 20 May 2015 16:44:35 +0200
> > Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> >
> > > Please Cristian, do not top post.
> > > I'm replacing your comment in the right context.
> > >
> > > 2015-05-20 13:57, Dumitrescu, Cristian:
> > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > > > Thanks for the detailed explanation.
> > > > >
> > > > > You are raising a trade-off problem about
> > > > > feature/maintenance/performance.
> > > > > I think we must choose among 4 solutions:
> > > > > 	1/ always enabled
> > > > > 	2/ build-time log level
> > > > > 	3/ run-time option
> > > > > 	4/ build-time option
> > > > >
> > > > > It's good to have this discussion and let other contributors givi=
ng their
> > > > > opinion.
> > > > >
> > > > > 2015-05-19 22:41, Dumitrescu, Cristian:
> > > > > > 1. What is the technical solution to avoid performance loss due=
 to
> stats
> > > > > > support?
> > > > > > Generally, I would agree with you that config options should be
> avoided,
> > > > > > especially those that alter the API (function prototypes, data
> structure
> > > > > > layouts, etc). Please note this is not the case for any of our =
patches,
> > > > > > as only the stats collection is enabled/disabled, while the dat=
a
> > > > > > structures and functions are not changed by the build time opti=
on.
> > > > > >
> > > > > > But what can you do for statistics? We all know that collecting=
 the
> stats
> > > > > > sucks up CPU cycles, especially due to memory accesses, so stat=
s
> always
> > > > > > have a run-time cost. Traditionally, stats are typically enable=
d for
> > > > > > debugging purposes and then turned off for the release version
> when
> > > > > > performance is required. How can this be done if build time fla=
gs are
> not
> > > > > > used?
> > > > >
> > > > > Statistics in drivers are always enabled (first solution).
> > > > > If those statistics are only used for debugging, why not using th=
e
> build-time
> > > > > option CONFIG_RTE_LOG_LEVEL? (second solution)
> > > >
> > > > Can you please describe what solution 2 on your list (build-time lo=
g
> > > > level) consists of?
> > > >
> > > > I see log level useful for printing messages when an event takes pl=
ace,
> > > > but this is not what these stats patches are about. We want to poll
> > > > for those counters on demand: if the build-time flag is off, then t=
he
> > > > value of those counters is 0; when the build-time is on, then the s=
tats
> > > > counters have the real value. Basically, the build-time flag only
> > > > enables/disables the update of the counters at run-time, which is
> where
> > > > CPU cycles are consumed. I am not sure how the log levels can help
> here?
> > >
> > > I think that counting stats is a kind of logging.
> > > Some stats are always counted (see drivers) and you want to use these
> ones
> > > only for debugging (after rebuilding DPDK with some debug options).
> > > So I suggest, as second solution, to check CONFIG_RTE_LOG_LEVEL is at
> debug
> > > level instead of having one option per module.
> > > It would be implemented with "#if RTE_LOG_LEVEL =3D=3D RTE_LOG_DEBUG"
> in
> > > RTE_PIPELINE_STATS_ADD.
> > >
> >
> > In my experience, per-queue or per-cpu statistics have no visible
> performance
> > impact. And every real world deployment wants statistics
>=20
> Yes. Maybe that having a benchmark with per-cpu stats would help to discu=
ss
> the first solution (stats always enabled).

What are per-cpu stats? Are you referring to the false sharing problem when=
 each cpu core maintains its own stats, but stats from several cores end up=
 being stores in the same cache line? We don't have this problem here.