From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id C854C5A8F for ; Thu, 29 Jan 2015 18:10:54 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 29 Jan 2015 09:10:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,486,1418112000"; d="scan'208";a="519734082" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga003.jf.intel.com with ESMTP; 29 Jan 2015 09:03:26 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.28]) by IRSMSX151.ger.corp.intel.com ([169.254.4.141]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 17:10:37 +0000 From: "Wodkowski, PawelX" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH 0/2] new headroom stats library and example application Thread-Index: AQHQO8cX3AhX/wsCZEq/jw6ZL+01+5zXRm3A Date: Thu, 29 Jan 2015 17:10:36 +0000 Message-ID: References: <1422532206-10662-1-git-send-email-pawelx.wodkowski@intel.com> <20150129132522.GA1999@hmsreliant.think-freely.org> In-Reply-To: <20150129132522.GA1999@hmsreliant.think-freely.org> Accept-Language: pl-PL, 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 0/2] new headroom stats library and example application 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: Thu, 29 Jan 2015 17:10:55 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Thursday, January 29, 2015 2:25 PM > To: Wodkowski, PawelX > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/2] new headroom stats library and exampl= e > application >=20 > On Thu, Jan 29, 2015 at 12:50:04PM +0100, Pawel Wodkowski wrote: > > Hi community, > > I would like to introduce library for measuring load of some arbitrary = jobs. It > > can be used to profile every kind of job sets on any arbitrary executio= n unit. > > In provided l2fwd-headroom example I demonstrate how to use this librar= y to > > profile packet forwarding (job set is froward, flush and stats) on LCor= es > > (execution unit). This example does no limit possible schemes on which = this > > library can be used. > > > > Pawel Wodkowski (2): > > librte_headroom: New library for checking core/system/app load > > examples: introduce new l2fwd-headroom example > > > > config/common_bsdapp | 6 + > > config/common_linuxapp | 6 + > > examples/Makefile | 1 + > > examples/l2fwd-headroom/Makefile | 51 +++ > > examples/l2fwd-headroom/main.c | 875 > ++++++++++++++++++++++++++++++++++++ > > lib/Makefile | 1 + > > lib/librte_headroom/Makefile | 50 +++ > > lib/librte_headroom/rte_headroom.c | 368 +++++++++++++++ > > lib/librte_headroom/rte_headroom.h | 481 ++++++++++++++++++++ > > mk/rte.app.mk | 4 + > > 10 files changed, 1843 insertions(+) > > create mode 100644 examples/l2fwd-headroom/Makefile > > create mode 100644 examples/l2fwd-headroom/main.c > > create mode 100644 lib/librte_headroom/Makefile > > create mode 100644 lib/librte_headroom/rte_headroom.c > > create mode 100644 lib/librte_headroom/rte_headroom.h > > > > -- > > 1.7.9.5 > > > > >=20 > Whats the advantage of this library over the other tools to preform the s= ame > function. Hi Neil, Good point, what is advantage over perf. Answer is: this library does not=20 supposed to be a perf competition and is not for profiling app in the way p= erf does. It is an small and fast extension. It's main task is to manage job list to = invoke them exactly when needed and provide some basic stats about application idl= e=20 time (whatever programmer will consider the idle) and busy time. For example: application might decide to add remove some jobs to/from LCore(s) dynamical= ly basing on current idle time (ex: move job from one core to another). Also application might have some information's about traffic type it handle= s and provide own algorithm to calculate invocation time (it can also dynamic= ally switch between those algorithms only replacing handlers). > Perf can provide all the information in this library, and do so > without having to directly modify the source for the execution unit under= test Yes, perf can provide those information's but it can't handle the case whe= n=20 you are poling for packets too fast or too slow and waist time getting only= couple=20 of them. Library will adjust time when it execute job basing on value this = job returned previously. Code modifications are not so deep, as you can see com= paring=20 l2wf vs l2fwd-headroom app. For example in application I introduced, when forward job return less than MAX_PKT_BURST execution period will be increased. If it return more it will= decrease execution period. Stats provided for that can be used to determine if appli= cation is behaving correctly and if there is a time for handling another port (what d= id for tests). Pawel