From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v5 0/3] new headroom stats library and example application Date: Mon, 23 Feb 2015 12:45:33 +0100 Message-ID: <3091068.GKVt00SAyB@xps13> 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: "Wodkowski, PawelX" Return-path: In-Reply-To: <60ABE07DBB3A454EB7FAD707B4BB1582138EB174-kPTMFJFq+rHjxeytcECX8bfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 2015-02-20 15:46, Jastrzebski, MichalX K: > From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.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?