2015-02-20 15:46, Jastrzebski, MichalX K: > From: dev [mailto:dev-bounces at 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?
