From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by dpdk.org (Postfix) with ESMTP id 02FFFADA6 for ; Mon, 23 Feb 2015 12:46:05 +0100 (CET) Received: by mail-wi0-f180.google.com with SMTP id h11so15914623wiw.1 for ; Mon, 23 Feb 2015 03:46:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=THR1Msvl1y0L4F9crmpO6Gml6pNdc/jamR85EOwhRRc=; b=mEEzyz8+muehEL6dcxTetjkHc8m34lXAubMcAWUtilwiiXP6xKCAm0Xf1FXeZ3OBxh 5jlDX5NNSINixRLYgsx7uCE9gEKPSIV6VXOV++Z1M7caJ4V+Gpv5AERYc0nVy7YLHGev t9K50H79J2iowyTb/SVmaBw4i/3LKTZrMsTVwqcWT9iPBifw+8yLcF/bLKAWCcnntDYV WXGliq31xo9j46R+GLZdSl/l4dYzhLuQ+w9klf6KsdITd/O8spDUW4Khyw6DvuXSyR1g v2uxnAb+R6VqmPg5hkAa77zURaiDYC+Ty8YLhQ0cFzDKR9+R+Z1GArpDyyRXylB6xeFI gYDg== X-Gm-Message-State: ALoCoQnnsZ1JQCn+2UfdHIblDtnk55NJrhA6vyBQYIA9UteAnypET8okICU4uh3t4r1ao8b+mjIp X-Received: by 10.194.200.233 with SMTP id jv9mr21723418wjc.51.1424691965831; Mon, 23 Feb 2015 03:46:05 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id j9sm55215249wjy.18.2015.02.23.03.46.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 03:46:04 -0800 (PST) From: Thomas Monjalon To: "Wodkowski, PawelX" Date: Mon, 23 Feb 2015 12:45:33 +0100 Message-ID: <3091068.GKVt00SAyB@xps13> Organization: 6WIND User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; ) In-Reply-To: <60ABE07DBB3A454EB7FAD707B4BB1582138EB174@IRSMSX109.ger.corp.intel.com> References: <1424191340-26451-1-git-send-email-pawelx.wodkowski@intel.com> <20150219143334.GH24069@hmsreliant.think-freely.org> <60ABE07DBB3A454EB7FAD707B4BB1582138EB174@IRSMSX109.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v5 0/3] 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: Mon, 23 Feb 2015 11:46:06 -0000 2015-02-20 15:46, Jastrzebski, MichalX K: > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman > > On Thu, Feb 19, 2015 at 01:18:41PM +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 execution unit > > > or tasking library. > > > > > > In provided l2fwd-headroom example I demonstrate how to use this library to > > > select optimal rx burst poll time. Jobs are selected by using existing rte_timer > > > library calls. This example does no limit possible schemes on which this > > > library can be used. > > > > > > Pawel Wodkowski (3): > > > librte_headroom: New library for checking core/system/app load > > > examples: introduce new l2fwd-headroom example > > > MAINTAINERS: claim responsibility for headroom library and example app > > > > I'm sorry but I still fail to see how this is a particularly useful library. It > > clearly works fine, but it composes an application event loop in its own > > terms, > > and measures stats based on that. While thats ok, any application is already > > going to have to write its own event loop, and can makethe same > > measurements > > synchnously within that loop, using alot less code to optimize its polling time. > > > > In other words, I think this is one of those cases where this library is > > probably somewhat useful for anyone who just wants to write an application > > in > > terms the semantics exposed by this library, but not at all useful for anyone > > else. I'd personally rather not have the extra code to maintain here. > > > > Stephen just gave a presentation at netdev about some of the performance > > optimization measurements Brocade did with DPDK and how they fine tuned > > their > > environment. One of the big take aways for me was that making time based > > measurements (especially if it was using the tsc), created cpu stalls that > > skewed the measurements, and so the best optimizations they made avoided > > time > > measurements, opting instead for packet count metrics. > > > > Neil > > Hi Neil, > > I think this library offers something quite useful probably not for everyone, > but for many people that use DPDK, and it is measuring quite accurately, > how many spare cycles a CPU have after executing any serial tasks (as you will know). > If you look at two places in example application: main_loop() > and l2fwd_fwd() functions, you will see two possible approach there, but > this is not limited to that. You can even nest headroom objects and measure > process time of particular packets type. > Of course, this will add an overhead due to the measurements, > but that time is also measured, so any user can know what is the relative > time "wasted" for measuring all this. > If time delays are measured in bigger timestamps, are handled reliably, > the cost of measuring will be low. > I find this quite similar to the power library case. I would say that library is not useful > for every application, but there are several cases where it can be > (as demonstrated with l3fwd-power app). > > About your last bit, not sure if I understood it right, but in case of the included sample app, > the main measurement to see if we are overusing a CPU is the packet count > in a queue (in this case RX queue), and I believe this should be used for other apps, > especially in those that use a pipeline model, where queues and rings are the key part. > > As a final point, last week (12th of February), there was a request for a tool/library like this > from a user in the mailing list (Ilan Borenshtein), which indicates that this would be useful > (probably not just for him, but for others). It probably could be achieved by the user > by adding their own code, but I believe this library would be a good-to-have, > in case a user is looking for an easy way to calculate the exposed above. > Let us give the users an example of this method and we will expand it with more > advanced application that may show capabilities of dynamic load scaling based on headroom library measurement. I wonder how this library is related to DPDK. I'm not against its integration, though the question must be asked. DPDK is a set of libraries. What kind of library fit with DPDK goals and deserve to be integrated? I don't know whether it's related but nobody acknowledged this patchset. I also feel that the name of this library is a bit too vague. Some people were asking first what means "headroom". It's actually for CPU headroom monitoring. What about "cpuheadroom", "cpuheadroomstat", "jobstat"? Last comment, less important: as many of your colleagues, you don't pay attention to the copyright dates. I'm pretty sure this code was not written in 2010. So why claiming it?