Hi Dave, Thanks for your suggestion.
As an attempt towards an alternate strategy, I did go ahead and make a change in the main loop of VPP18.01 (similar change as I describe below should be valid much in a similar fashion to subsequent releases) and it seems to be working for me, but there might be many catches so I am disclosing what I did below. In vlib_main_or_worker_loop, on a per thread basis, I accumulated time in the following areas :- . vl_api_send_pending_rpc_requests (if there were indeed some pending) . dispatch_node (if the node's callback returned n > 0) . vlib_frame_queue_dequeue (again if return value was > 0) The above acted as a numerator for a sampling time of 1 second, the denominator. At the stroke of this window, I divide, store result and clear all accumulations to begin afresh. The calculations are valid only for worker threads as I don't care for main thread whose cpu is reported by linux anyway. Empirically it seems to work ok for me. I did check by making my own plugins quite busy and so forth. Do you think, the above is a reasonable custom strategy or is there a chance of destroying performance of main loop (and thus the whole system) due to frequent calls to vlib_time_now, would appreciate if you can give your opinion. Regards -Prashant On Fri, Jun 7, 2019 at 5:22 PM Dave Barach (dbarach) <dbar...@cisco.com> wrote: > > The instantaneous vector size - in the stats segment, per-thread - is the > best measure of how hard vpp is working. > > > > It's not a linear function of the offered load, but for any given offered > load / feature set you can model it with three segments: > > > > Dead asleep: vector size < 3, offered load up to maybe 1 mpps’ worth of > simple forwarding > Linear region: vector size increases smoothly as offered load increases, up a > vector size of maybe 128 or so > Hit the wall: a slight increate in offered load causes a huge jump in the > vector size, traffic loss, etc. > > > > HTH... Dave > > > > -----Original Message----- > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Prashant > Upadhyaya > Sent: Friday, June 7, 2019 5:41 AM > To: vpp-dev@lists.fd.io > Subject: [vpp-dev] Approximate effective CPU utilization of VPP worker > > > > Hi, > > > > I understand that VPP workers poll so they are always at 100 % CPU. > > However, I want to get an estimate of what is the effective CPU utilization > i.e. the amount which was spent in doing the work for packet processing. > > > > In the native applications, the crude way I used to employ was to take a time > window of say 1 second and I already know how many cpu cycles it is worth, > this acted as the denominator. Then in every packet poll, I used to count the > cycles spent when the packet was actually brought in and processed. So empty > polls were not counted in the used cycles. > > This acted like the numerator. When the window was exhausted, I used the > numerator/denominator to get an approximation of effective CPU utilization of > the worker. > > > > Is something like this already possible in VPP, I need to constantly monitor > the effective CPU utilization of the worker at runtime to take some decisions > and inform the system peers eg. to reduce sending traffic etc. > > > > Regards > > -Prashant
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13245): https://lists.fd.io/g/vpp-dev/message/13245 Mute This Topic: https://lists.fd.io/mt/31973018/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
