We've added purpose-built callback hooks in the main dispatch loop [in 
master/latest] so that folks can hook up whatever sort of instrumentation they 
like. Please have a look at that scheme.

There's no point in attempting to upstream your work to stable/1801. We long 
since shut down the CSIT performance jobs for 18.01, and we will not merge 
feature patches into stable/1801.

Many things have changed since 18.01 - thousands of patches' worth, including 
significant performance tunes and a new build system - IIWY I'd rebase to 19.04 
and/or master/latest.

HTH... Dave 

-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Prashant Upadhyaya
Sent: Monday, June 10, 2019 6:13 AM
To: Dave Barach (dbarach) <dbar...@cisco.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Approximate effective CPU utilization of VPP worker

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 (#13246): https://lists.fd.io/g/vpp-dev/message/13246
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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to