Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread bjeremy32
I think I was going to try and write something more acceptable to be merged, 
but if you end up getting it working, then you may want to offer that as a 
solution to the community.

 

From: vpp-dev@lists.fd.io  On Behalf Of Ramkumar
Sent: Thursday, December 17, 2020 3:56 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

 

Thanks bjeremy32 for sharing the patch! 
As mentioned by Dave, I have implemented load calculation in a plugin. I can 
try to reevaluate my implementation with yours as reference. Will let you know 
if I get it working. 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18397): https://lists.fd.io/g/vpp-dev/message/18397
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread Ramkumar
Thanks bjeremy32 for sharing the patch!
As mentioned by Dave, I have implemented load calculation in a plugin. I can 
try to reevaluate my implementation with yours as reference. Will let you know 
if I get it working.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18395): https://lists.fd.io/g/vpp-dev/message/18395
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread bjeremy32
If you want to refactor it in a way to fit the code architecture better, feel 
free.

 

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach
Sent: Thursday, December 17, 2020 1:43 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

 

As the sole remaining original vpp author and the area maintainer, I have 
abundant experience dealing with src/vlib/{main.c, threads.c}. 

 

In every case to date, we’ve been able to leverage existing callback hooks, or 
to add callback hooks so that folks can do what they need to do (e.g. from 
plugins) without modifying the core engine.

 

Might we manage to take that approach here? It’s in everyone’s interest to do 
so...

 

Thanks... Dave

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18394): https://lists.fd.io/g/vpp-dev/message/18394
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread Dave Barach
As the sole remaining original vpp author and the area maintainer, I have 
abundant experience dealing with src/vlib/{main.c, threads.c}.

In every case to date, we’ve been able to leverage existing callback hooks, or 
to add callback hooks so that folks can do what they need to do (e.g. from 
plugins) without modifying the core engine.

Might we manage to take that approach here? It’s in everyone’s interest to do 
so...

Thanks... Dave

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18393): https://lists.fd.io/g/vpp-dev/message/18393
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread bjeremy32
Ramkumar,

 

Attached are the patches to 20.05 to implement the cpu usage… I think this was 
all that was changed. You may want to hand merge them instead of applying the 
patches though, It may be ok… but im not 100% other lines were not touched.

 

You will be able to view cpu usage with:  ‘watch vppctl show threads’. 

 

As I said, it seems to work rather well for us. We run in various 
configurations. But your particular case may be different and require some 
other tweaking, but this just illustrates the idea… 

 

1.  Grouped no handoff - all rcv queues handled by a single core, no handoff
2.  Grouped with handoff
3.  Separated cores with handoff – each separate core handles a rcv queue, 
handoffs work to a separate thread
4.  Separated cores no handoff

 

In all cases, it seems the cpu usage metric is fairly accurate. We notice as 
pps increases for us packet start dropping at about 90%. And for worker threads 
(not in poll mode) we could compare the cpu usage using htop with our patch… it 
was within 1-2% which was good enough…

 

 

From: vpp-dev@lists.fd.io  On Behalf Of bjeremy32 via 
lists.fd.io
Sent: Wednesday, December 16, 2020 11:14 AM
To: 'Ramkumar B' 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

 

If it will help, I will share my patch as soon as I get authorization from my 
corporate overlords.

 

From: Ramkumar B mailto:ramukmar1...@gmail.com> > 
Sent: Wednesday, December 16, 2020 11:08 AM
To: bjerem...@gmail.com <mailto:bjerem...@gmail.com> 
Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 




I got your idea. Thanks for taking time to clarify. I kind of tried the same 
but in vain. I think I will look into this solution again.

 

On Wed, Dec 16, 2020 at 10:21 PM mailto:bjerem...@gmail.com> > wrote:

In dispatch_node, before we call node->function any accumulated clock cycles 
are counted toward idle, after the node->function returns if ( 
(VLIB_NODE_TYPE_PRE_INPUT || VLIB_NODE_TYPE_INPUT) && number of packets 
processed == 0) then we count it as idle, else we count it as busy.

 

 

From: Ramkumar B mailto:ramukmar1...@gmail.com> > 
Sent: Wednesday, December 16, 2020 10:27 AM
To: bjerem...@gmail.com <mailto:bjerem...@gmail.com> 
Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

The processing of the rx queue is counted toward IDLE

Please explain what kind of processing. We are not doing any such rx processing 
separately. For us, the ring_dequeue_burst's cycles is negligible compared to 
processing cycles.

 

On Wed, Dec 16, 2020 at 8:54 PM mailto:bjerem...@gmail.com> > wrote:

Nope… the math works out… nothing goes to 0… we are incrementing both IDLE and 
BUSY. The processing of the rx queue is counted toward IDLE… In a completely 
idle system, the cpu usage falls to 0… as traffic ramps up it will go further 
positive based on pps, and as it goes to idle again it will go down to 0…

 

 

From: Damjan Marion mailto:dmar...@me.com> > 
Sent: Wednesday, December 16, 2020 3:00 AM
To: bjerem...@gmail.com <mailto:bjerem...@gmail.com> 
Cc: Nick Zavaritsky mailto:nick.zavarit...@emnify.com> >; ramukmar1...@gmail.com 
<mailto:ramukmar1...@gmail.com> ; vpp-dev@lists.fd.io 
<mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

 

 

On 16.12.2020., at 05:45, bjerem...@gmail.com <mailto:bjerem...@gmail.com>  
wrote:

 

What we did was to count clock cycles (timestamps) spent processing the nodes, 
call this busy, and count the clock cycles spent elsewhere, call this idle. And 
then simply output (busy/(busy + idle). We did this per thread and stored the 
calculations globally. We then outputted the calculations on the ‘vppctl show 
thread’ cli.

 

This doesnt make lot of sense. Each input node is spending cycles to process rx 
queue, and out of that processing there may be zero or non-zero packets. So in 
completelly idle system according to your math result will be far away from 0.

 

 

 

This created a nice cpu usage metric that seems pretty accurate for io and 
worker threads…

 

What do you mean by io threads?

 

We compared this to something like htop for the worker threads and its within 
~1%, the io cores seem the same as we can see the usage go to about 80-90% when 
we start dropping packets. We are able to calculate the approx. PPS for a given 
system configuration.

 

It actually wasn’t a lot of effort. I think only three files were touched. 1. A 
new header file o create the global data structure to hold the clock cycle 
counts and associated macros to init and update the structures. 2. Vlib/main.c 
to instrument the main loop and collect the busy/idle clock cycles 3. Vlib 
threads_cli.c as show threads fn was used to output the cpu usage per thread.

 

From: vpp-dev@lists.fd.io <mailto:vpp-de

Re: [vpp-dev] Core Load Calculation

2020-12-16 Thread bjeremy32
If it will help, I will share my patch as soon as I get authorization from my 
corporate overlords.

 

From: Ramkumar B  
Sent: Wednesday, December 16, 2020 11:08 AM
To: bjerem...@gmail.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

 




I got your idea. Thanks for taking time to clarify. I kind of tried the same 
but in vain. I think I will look into this solution again.

 

On Wed, Dec 16, 2020 at 10:21 PM mailto:bjerem...@gmail.com> > wrote:

In dispatch_node, before we call node->function any accumulated clock cycles 
are counted toward idle, after the node->function returns if ( 
(VLIB_NODE_TYPE_PRE_INPUT || VLIB_NODE_TYPE_INPUT) && number of packets 
processed == 0) then we count it as idle, else we count it as busy.

 

 

From: Ramkumar B mailto:ramukmar1...@gmail.com> > 
Sent: Wednesday, December 16, 2020 10:27 AM
To: bjerem...@gmail.com <mailto:bjerem...@gmail.com> 
Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

The processing of the rx queue is counted toward IDLE

Please explain what kind of processing. We are not doing any such rx processing 
separately. For us, the ring_dequeue_burst's cycles is negligible compared to 
processing cycles.

 

On Wed, Dec 16, 2020 at 8:54 PM mailto:bjerem...@gmail.com> > wrote:

Nope… the math works out… nothing goes to 0… we are incrementing both IDLE and 
BUSY. The processing of the rx queue is counted toward IDLE… In a completely 
idle system, the cpu usage falls to 0… as traffic ramps up it will go further 
positive based on pps, and as it goes to idle again it will go down to 0…

 

 

From: Damjan Marion mailto:dmar...@me.com> > 
Sent: Wednesday, December 16, 2020 3:00 AM
To: bjerem...@gmail.com <mailto:bjerem...@gmail.com> 
Cc: Nick Zavaritsky mailto:nick.zavarit...@emnify.com> >; ramukmar1...@gmail.com 
<mailto:ramukmar1...@gmail.com> ; vpp-dev@lists.fd.io 
<mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

 

 

On 16.12.2020., at 05:45, bjerem...@gmail.com <mailto:bjerem...@gmail.com>  
wrote:

 

What we did was to count clock cycles (timestamps) spent processing the nodes, 
call this busy, and count the clock cycles spent elsewhere, call this idle. And 
then simply output (busy/(busy + idle). We did this per thread and stored the 
calculations globally. We then outputted the calculations on the ‘vppctl show 
thread’ cli.

 

This doesnt make lot of sense. Each input node is spending cycles to process rx 
queue, and out of that processing there may be zero or non-zero packets. So in 
completelly idle system according to your math result will be far away from 0.

 

 

 

This created a nice cpu usage metric that seems pretty accurate for io and 
worker threads…

 

What do you mean by io threads?

 

We compared this to something like htop for the worker threads and its within 
~1%, the io cores seem the same as we can see the usage go to about 80-90% when 
we start dropping packets. We are able to calculate the approx. PPS for a given 
system configuration.

 

It actually wasn’t a lot of effort. I think only three files were touched. 1. A 
new header file o create the global data structure to hold the clock cycle 
counts and associated macros to init and update the structures. 2. Vlib/main.c 
to instrument the main loop and collect the busy/idle clock cycles 3. Vlib 
threads_cli.c as show threads fn was used to output the cpu usage per thread.

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Nick Zavaritsky
Sent: Tuesday, December 15, 2020 1:38 PM
To: ramukmar1...@gmail.com <mailto:ramukmar1...@gmail.com> 
Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

We’ve been using flamegraphs quite successfully to see how much leeway is there.

 

Ex: 
https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg

 

On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io <http://lists.fd.io/>  
mailto:ramukmar1998=gmail@lists.fd.io> 
> wrote:
 

Hello All,

 

I'm trying to calculate VPP core's load. I completely understand about the 
polling cores' 100% CPU usage. My requirement is different where I need to 
calculate the core's load based on how much more PPS it can handle before a 
packet drop occurs in the queue.

 

The vec/call is a good indicator of load, but it does not increase linearly 
with PPS. This is because of the VPP's self balancing behaviour where the cost 
per packet reduces as load increases. It would be a great help if anyone can 
point out factors to calculate load.

 

Thanks and regards, 

Ramkumar Balu

 




 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18377): https://lists.fd.io/g

Re: [vpp-dev] Core Load Calculation

2020-12-16 Thread Ramkumar B
I got your idea. Thanks for taking time to clarify. I kind of tried the
same but in vain. I think I will look into this solution again.

On Wed, Dec 16, 2020 at 10:21 PM  wrote:

> In dispatch_node, before we call node->function any accumulated clock
> cycles are counted toward idle, after the node->function returns if (
> (VLIB_NODE_TYPE_PRE_INPUT || VLIB_NODE_TYPE_INPUT) && number of packets
> processed == 0) then we count it as idle, else we count it as busy.
>
>
>
>
>
> *From:* Ramkumar B 
> *Sent:* Wednesday, December 16, 2020 10:27 AM
> *To:* bjerem...@gmail.com
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Core Load Calculation
>
>
>
> The processing of the rx queue is counted toward IDLE
>
> Please explain what kind of processing. We are not doing any such rx
> processing separately. For us, the ring_dequeue_burst's cycles
> is negligible compared to processing cycles.
>
>
>
> On Wed, Dec 16, 2020 at 8:54 PM  wrote:
>
> Nope… the math works out… nothing goes to 0… we are incrementing both IDLE
> and BUSY. The processing of the rx queue is counted toward IDLE… In a
> completely idle system, the cpu usage falls to 0… as traffic ramps up it
> will go further positive based on pps, and as it goes to idle again it will
> go down to 0…
>
>
>
>
>
> *From:* Damjan Marion 
> *Sent:* Wednesday, December 16, 2020 3:00 AM
> *To:* bjerem...@gmail.com
> *Cc:* Nick Zavaritsky ; ramukmar1...@gmail.com;
> vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Core Load Calculation
>
>
>
>
>
>
>
> On 16.12.2020., at 05:45, bjerem...@gmail.com wrote:
>
>
>
> What we did was to count clock cycles (timestamps) spent processing the
> nodes, call this busy, and count the clock cycles spent elsewhere, call
> this idle. And then simply output (busy/(busy + idle). We did this per
> thread and stored the calculations globally. We then outputted the
> calculations on the ‘vppctl show thread’ cli.
>
>
>
> This doesnt make lot of sense. Each input node is spending cycles to
> process rx queue, and out of that processing there may be zero or non-zero
> packets. So in completelly idle system according to your math result will
> be far away from 0.
>
>
>
>
>
>
>
> This created a nice cpu usage metric that seems pretty accurate for io and
> worker threads…
>
>
>
> What do you mean by io threads?
>
>
>
> We compared this to something like htop for the worker threads and its
> within ~1%, the io cores seem the same as we can see the usage go to about
> 80-90% when we start dropping packets. We are able to calculate the approx.
> PPS for a given system configuration.
>
>
>
> It actually wasn’t a lot of effort. I think only three files were touched.
> 1. A new header file o create the global data structure to hold the clock
> cycle counts and associated macros to init and update the structures. 2.
> Vlib/main.c to instrument the main loop and collect the busy/idle clock
> cycles 3. Vlib threads_cli.c as show threads fn was used to output the cpu
> usage per thread.
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Nick
> Zavaritsky
> *Sent:* Tuesday, December 15, 2020 1:38 PM
> *To:* ramukmar1...@gmail.com
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Core Load Calculation
>
>
>
> We’ve been using flamegraphs quite successfully to see how much leeway is
> there.
>
>
>
> Ex:
> https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg
>
>
>
> On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io <
> ramukmar1998=gmail@lists.fd.io> wrote:
>
>
> Hello All,
>
>
>
> I'm trying to calculate VPP core's load. I completely understand about the
> polling cores' 100% CPU usage. My requirement is different where I need to
> calculate the core's load based on how much more PPS it can handle before a
> packet drop occurs in the queue.
>
>
>
> The vec/call is a good indicator of load, but it does not increase
> linearly with PPS. This is because of the VPP's self balancing behaviour
> where the cost per packet reduces as load increases. It would be a great
> help if anyone can point out factors to calculate load.
>
>
>
> Thanks and regards,
>
> Ramkumar Balu
>
>
>
>
> 
>
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18375): https://lists.fd.io/g/vpp-dev/message/18375
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-16 Thread Damjan Marion via lists.fd.io

Glad to hear it works for you :)

— 
Damjan

> On 16.12.2020., at 17:51, bjerem...@gmail.com wrote:
> 
> In dispatch_node, before we call node->function any accumulated clock cycles 
> are counted toward idle, after the node->function returns if ( 
> (VLIB_NODE_TYPE_PRE_INPUT || VLIB_NODE_TYPE_INPUT) && number of packets 
> processed == 0) then we count it as idle, else we count it as busy.
>
>
> From: Ramkumar B mailto:ramukmar1...@gmail.com>> 
> Sent: Wednesday, December 16, 2020 10:27 AM
> To: bjerem...@gmail.com <mailto:bjerem...@gmail.com>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] Core Load Calculation
>
> The processing of the rx queue is counted toward IDLE
> Please explain what kind of processing. We are not doing any such rx 
> processing separately. For us, the ring_dequeue_burst's cycles is negligible 
> compared to processing cycles.
>
> On Wed, Dec 16, 2020 at 8:54 PM  <mailto:bjerem...@gmail.com>> wrote:
> Nope… the math works out… nothing goes to 0… we are incrementing both IDLE 
> and BUSY. The processing of the rx queue is counted toward IDLE… In a 
> completely idle system, the cpu usage falls to 0… as traffic ramps up it will 
> go further positive based on pps, and as it goes to idle again it will go 
> down to 0…
>
>
> From: Damjan Marion mailto:dmar...@me.com>> 
> Sent: Wednesday, December 16, 2020 3:00 AM
> To: bjerem...@gmail.com <mailto:bjerem...@gmail.com>
> Cc: Nick Zavaritsky  <mailto:nick.zavarit...@emnify.com>>; ramukmar1...@gmail.com 
> <mailto:ramukmar1...@gmail.com>; vpp-dev@lists.fd.io 
> <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] Core Load Calculation
>
>
>
> 
> On 16.12.2020., at 05:45, bjerem...@gmail.com <mailto:bjerem...@gmail.com> 
> wrote:
>
> What we did was to count clock cycles (timestamps) spent processing the 
> nodes, call this busy, and count the clock cycles spent elsewhere, call this 
> idle. And then simply output (busy/(busy + idle). We did this per thread and 
> stored the calculations globally. We then outputted the calculations on the 
> ‘vppctl show thread’ cli.
>
> This doesnt make lot of sense. Each input node is spending cycles to process 
> rx queue, and out of that processing there may be zero or non-zero packets. 
> So in completelly idle system according to your math result will be far away 
> from 0.
>
>
> 
>
> This created a nice cpu usage metric that seems pretty accurate for io and 
> worker threads…
>
> What do you mean by io threads?
>
> 
> We compared this to something like htop for the worker threads and its within 
> ~1%, the io cores seem the same as we can see the usage go to about 80-90% 
> when we start dropping packets. We are able to calculate the approx. PPS for 
> a given system configuration.
>
> It actually wasn’t a lot of effort. I think only three files were touched. 1. 
> A new header file o create the global data structure to hold the clock cycle 
> counts and associated macros to init and update the structures. 2. 
> Vlib/main.c to instrument the main loop and collect the busy/idle clock 
> cycles 3. Vlib threads_cli.c as show threads fn was used to output the cpu 
> usage per thread.
>
> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  <mailto:vpp-dev@lists.fd.io>> On Behalf Of Nick Zavaritsky
> Sent: Tuesday, December 15, 2020 1:38 PM
> To: ramukmar1...@gmail.com <mailto:ramukmar1...@gmail.com>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] Core Load Calculation
>
> We’ve been using flamegraphs quite successfully to see how much leeway is 
> there.
>
> Ex: 
> https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg
>  
> <https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg>
> 
> 
> On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io <http://lists.fd.io/> 
>  <mailto:ramukmar1998=gmail@lists.fd.io>> wrote:
>
> Hello All,
>
> I'm trying to calculate VPP core's load. I completely understand about the 
> polling cores' 100% CPU usage. My requirement is different where I need to 
> calculate the core's load based on how much more PPS it can handle before a 
> packet drop occurs in the queue.
>
> The vec/call is a good indicator of load, but it does not increase linearly 
> with PPS. This is because of the VPP's self balancing behaviour where the 
> cost per packet reduces as load increases. It would be a great help if anyone 
> can point out factors to calculate load.
>
> Thanks and regards, 
> Ramkumar Balu
> 
> 
> 
> 
>
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18373): https://lists.fd.io/g/vpp-dev/message/18373
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-16 Thread bjeremy32
In dispatch_node, before we call node->function any accumulated clock cycles 
are counted toward idle, after the node->function returns if ( 
(VLIB_NODE_TYPE_PRE_INPUT || VLIB_NODE_TYPE_INPUT) && number of packets 
processed == 0) then we count it as idle, else we count it as busy.

 

 

From: Ramkumar B  
Sent: Wednesday, December 16, 2020 10:27 AM
To: bjerem...@gmail.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

 

The processing of the rx queue is counted toward IDLE

Please explain what kind of processing. We are not doing any such rx processing 
separately. For us, the ring_dequeue_burst's cycles is negligible compared to 
processing cycles.

 

On Wed, Dec 16, 2020 at 8:54 PM mailto:bjerem...@gmail.com> > wrote:

Nope… the math works out… nothing goes to 0… we are incrementing both IDLE and 
BUSY. The processing of the rx queue is counted toward IDLE… In a completely 
idle system, the cpu usage falls to 0… as traffic ramps up it will go further 
positive based on pps, and as it goes to idle again it will go down to 0…

 

 

From: Damjan Marion mailto:dmar...@me.com> > 
Sent: Wednesday, December 16, 2020 3:00 AM
To: bjerem...@gmail.com <mailto:bjerem...@gmail.com> 
Cc: Nick Zavaritsky mailto:nick.zavarit...@emnify.com> >; ramukmar1...@gmail.com 
<mailto:ramukmar1...@gmail.com> ; vpp-dev@lists.fd.io 
<mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

 

 

On 16.12.2020., at 05:45, bjerem...@gmail.com <mailto:bjerem...@gmail.com>  
wrote:

 

What we did was to count clock cycles (timestamps) spent processing the nodes, 
call this busy, and count the clock cycles spent elsewhere, call this idle. And 
then simply output (busy/(busy + idle). We did this per thread and stored the 
calculations globally. We then outputted the calculations on the ‘vppctl show 
thread’ cli.

 

This doesnt make lot of sense. Each input node is spending cycles to process rx 
queue, and out of that processing there may be zero or non-zero packets. So in 
completelly idle system according to your math result will be far away from 0.

 

 

 

This created a nice cpu usage metric that seems pretty accurate for io and 
worker threads…

 

What do you mean by io threads?

 

We compared this to something like htop for the worker threads and its within 
~1%, the io cores seem the same as we can see the usage go to about 80-90% when 
we start dropping packets. We are able to calculate the approx. PPS for a given 
system configuration.

 

It actually wasn’t a lot of effort. I think only three files were touched. 1. A 
new header file o create the global data structure to hold the clock cycle 
counts and associated macros to init and update the structures. 2. Vlib/main.c 
to instrument the main loop and collect the busy/idle clock cycles 3. Vlib 
threads_cli.c as show threads fn was used to output the cpu usage per thread.

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Nick Zavaritsky
Sent: Tuesday, December 15, 2020 1:38 PM
To: ramukmar1...@gmail.com <mailto:ramukmar1...@gmail.com> 
Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

We’ve been using flamegraphs quite successfully to see how much leeway is there.

 

Ex: 
https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg





On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io <http://lists.fd.io/>  
mailto:ramukmar1998=gmail@lists.fd.io> 
> wrote:
 

Hello All,

 

I'm trying to calculate VPP core's load. I completely understand about the 
polling cores' 100% CPU usage. My requirement is different where I need to 
calculate the core's load based on how much more PPS it can handle before a 
packet drop occurs in the queue.

 

The vec/call is a good indicator of load, but it does not increase linearly 
with PPS. This is because of the VPP's self balancing behaviour where the cost 
per packet reduces as load increases. It would be a great help if anyone can 
point out factors to calculate load.

 

Thanks and regards, 

Ramkumar Balu








 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18372): https://lists.fd.io/g/vpp-dev/message/18372
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-16 Thread Ramkumar B
Yeah idle is when the input node doesn't get packets while polling. Other
nodes will not be scheduled without packets.
And as I said, the rx cycles is negligible..

On Wed, Dec 16, 2020 at 10:00 PM  wrote:

> Also.. forgot to mention… if a node doesn’t process any packets… it is
> counted as idle, else busy
>
>
>
> *From:* bjerem...@gmail.com 
> *Sent:* Wednesday, December 16, 2020 9:25 AM
> *To:* 'Damjan Marion' 
> *Cc:* 'Nick Zavaritsky' ;
> ramukmar1...@gmail.com; vpp-dev@lists.fd.io
> *Subject:* RE: [vpp-dev] Core Load Calculation
>
>
>
> Nope… the math works out… nothing goes to 0… we are incrementing both IDLE
> and BUSY. The processing of the rx queue is counted toward IDLE… In a
> completely idle system, the cpu usage falls to 0… as traffic ramps up it
> will go further positive based on pps, and as it goes to idle again it will
> go down to 0…
>
>
>
>
>
> *From:* Damjan Marion 
> *Sent:* Wednesday, December 16, 2020 3:00 AM
> *To:* bjerem...@gmail.com
> *Cc:* Nick Zavaritsky ; ramukmar1...@gmail.com;
> vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Core Load Calculation
>
>
>
>
>
>
>
> On 16.12.2020., at 05:45, bjerem...@gmail.com wrote:
>
>
>
> What we did was to count clock cycles (timestamps) spent processing the
> nodes, call this busy, and count the clock cycles spent elsewhere, call
> this idle. And then simply output (busy/(busy + idle). We did this per
> thread and stored the calculations globally. We then outputted the
> calculations on the ‘vppctl show thread’ cli.
>
>
>
> This doesnt make lot of sense. Each input node is spending cycles to
> process rx queue, and out of that processing there may be zero or non-zero
> packets. So in completelly idle system according to your math result will
> be far away from 0.
>
>
>
>
>
>
>
> This created a nice cpu usage metric that seems pretty accurate for io and
> worker threads…
>
>
>
> What do you mean by io threads?
>
>
>
> We compared this to something like htop for the worker threads and its
> within ~1%, the io cores seem the same as we can see the usage go to about
> 80-90% when we start dropping packets. We are able to calculate the approx.
> PPS for a given system configuration.
>
>
>
> It actually wasn’t a lot of effort. I think only three files were touched.
> 1. A new header file o create the global data structure to hold the clock
> cycle counts and associated macros to init and update the structures. 2.
> Vlib/main.c to instrument the main loop and collect the busy/idle clock
> cycles 3. Vlib threads_cli.c as show threads fn was used to output the cpu
> usage per thread.
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Nick
> Zavaritsky
> *Sent:* Tuesday, December 15, 2020 1:38 PM
> *To:* ramukmar1...@gmail.com
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Core Load Calculation
>
>
>
> We’ve been using flamegraphs quite successfully to see how much leeway is
> there.
>
>
>
> Ex:
> https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg
>
>
>
> On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io <
> ramukmar1998=gmail@lists.fd.io> wrote:
>
>
> Hello All,
>
>
>
> I'm trying to calculate VPP core's load. I completely understand about the
> polling cores' 100% CPU usage. My requirement is different where I need to
> calculate the core's load based on how much more PPS it can handle before a
> packet drop occurs in the queue.
>
>
>
> The vec/call is a good indicator of load, but it does not increase
> linearly with PPS. This is because of the VPP's self balancing behaviour
> where the cost per packet reduces as load increases. It would be a great
> help if anyone can point out factors to calculate load.
>
>
>
> Thanks and regards,
>
> Ramkumar Balu
>
>
>
>
> 
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18371): https://lists.fd.io/g/vpp-dev/message/18371
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-16 Thread bjeremy32
Also.. forgot to mention… if a node doesn’t process any packets… it is counted 
as idle, else busy

 

From: bjerem...@gmail.com  
Sent: Wednesday, December 16, 2020 9:25 AM
To: 'Damjan Marion' 
Cc: 'Nick Zavaritsky' ; ramukmar1...@gmail.com; 
vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] Core Load Calculation

 

Nope… the math works out… nothing goes to 0… we are incrementing both IDLE and 
BUSY. The processing of the rx queue is counted toward IDLE… In a completely 
idle system, the cpu usage falls to 0… as traffic ramps up it will go further 
positive based on pps, and as it goes to idle again it will go down to 0…

 

 

From: Damjan Marion mailto:dmar...@me.com> > 
Sent: Wednesday, December 16, 2020 3:00 AM
To: bjerem...@gmail.com <mailto:bjerem...@gmail.com> 
Cc: Nick Zavaritsky mailto:nick.zavarit...@emnify.com> >; ramukmar1...@gmail.com 
<mailto:ramukmar1...@gmail.com> ; vpp-dev@lists.fd.io 
<mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

 

 

On 16.12.2020., at 05:45, bjerem...@gmail.com <mailto:bjerem...@gmail.com>  
wrote:

 

What we did was to count clock cycles (timestamps) spent processing the nodes, 
call this busy, and count the clock cycles spent elsewhere, call this idle. And 
then simply output (busy/(busy + idle). We did this per thread and stored the 
calculations globally. We then outputted the calculations on the ‘vppctl show 
thread’ cli.

 

This doesnt make lot of sense. Each input node is spending cycles to process rx 
queue, and out of that processing there may be zero or non-zero packets. So in 
completelly idle system according to your math result will be far away from 0.

 

 

 

This created a nice cpu usage metric that seems pretty accurate for io and 
worker threads…

 

What do you mean by io threads?

 

We compared this to something like htop for the worker threads and its within 
~1%, the io cores seem the same as we can see the usage go to about 80-90% when 
we start dropping packets. We are able to calculate the approx. PPS for a given 
system configuration.

 

It actually wasn’t a lot of effort. I think only three files were touched. 1. A 
new header file o create the global data structure to hold the clock cycle 
counts and associated macros to init and update the structures. 2. Vlib/main.c 
to instrument the main loop and collect the busy/idle clock cycles 3. Vlib 
threads_cli.c as show threads fn was used to output the cpu usage per thread.

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Nick Zavaritsky
Sent: Tuesday, December 15, 2020 1:38 PM
To: ramukmar1...@gmail.com <mailto:ramukmar1...@gmail.com> 
Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

We’ve been using flamegraphs quite successfully to see how much leeway is there.

 

Ex: 
https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg





On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io <http://lists.fd.io/>  
mailto:ramukmar1998=gmail@lists.fd.io> 
> wrote:
 

Hello All,

 

I'm trying to calculate VPP core's load. I completely understand about the 
polling cores' 100% CPU usage. My requirement is different where I need to 
calculate the core's load based on how much more PPS it can handle before a 
packet drop occurs in the queue.

 

The vec/call is a good indicator of load, but it does not increase linearly 
with PPS. This is because of the VPP's self balancing behaviour where the cost 
per packet reduces as load increases. It would be a great help if anyone can 
point out factors to calculate load.

 

Thanks and regards, 

Ramkumar Balu








 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18369): https://lists.fd.io/g/vpp-dev/message/18369
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-16 Thread Ramkumar B
The processing of the rx queue is counted toward IDLE
Please explain what kind of processing. We are not doing any such rx
processing separately. For us, the ring_dequeue_burst's cycles
is negligible compared to processing cycles.

On Wed, Dec 16, 2020 at 8:54 PM  wrote:

> Nope… the math works out… nothing goes to 0… we are incrementing both IDLE
> and BUSY. The processing of the rx queue is counted toward IDLE… In a
> completely idle system, the cpu usage falls to 0… as traffic ramps up it
> will go further positive based on pps, and as it goes to idle again it will
> go down to 0…
>
>
>
>
>
> *From:* Damjan Marion 
> *Sent:* Wednesday, December 16, 2020 3:00 AM
> *To:* bjerem...@gmail.com
> *Cc:* Nick Zavaritsky ; ramukmar1...@gmail.com;
> vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Core Load Calculation
>
>
>
>
>
>
>
> On 16.12.2020., at 05:45, bjerem...@gmail.com wrote:
>
>
>
> What we did was to count clock cycles (timestamps) spent processing the
> nodes, call this busy, and count the clock cycles spent elsewhere, call
> this idle. And then simply output (busy/(busy + idle). We did this per
> thread and stored the calculations globally. We then outputted the
> calculations on the ‘vppctl show thread’ cli.
>
>
>
> This doesnt make lot of sense. Each input node is spending cycles to
> process rx queue, and out of that processing there may be zero or non-zero
> packets. So in completelly idle system according to your math result will
> be far away from 0.
>
>
>
>
>
>
>
> This created a nice cpu usage metric that seems pretty accurate for io and
> worker threads…
>
>
>
> What do you mean by io threads?
>
>
>
> We compared this to something like htop for the worker threads and its
> within ~1%, the io cores seem the same as we can see the usage go to about
> 80-90% when we start dropping packets. We are able to calculate the approx.
> PPS for a given system configuration.
>
>
>
> It actually wasn’t a lot of effort. I think only three files were touched.
> 1. A new header file o create the global data structure to hold the clock
> cycle counts and associated macros to init and update the structures. 2.
> Vlib/main.c to instrument the main loop and collect the busy/idle clock
> cycles 3. Vlib threads_cli.c as show threads fn was used to output the cpu
> usage per thread.
>
>
>
> *From:* vpp-dev@lists.fd.io  *On Behalf Of *Nick
> Zavaritsky
> *Sent:* Tuesday, December 15, 2020 1:38 PM
> *To:* ramukmar1...@gmail.com
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Core Load Calculation
>
>
>
> We’ve been using flamegraphs quite successfully to see how much leeway is
> there.
>
>
>
> Ex:
> https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg
>
>
>
>
> On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io <
> ramukmar1998=gmail@lists.fd.io> wrote:
>
>
> Hello All,
>
>
>
> I'm trying to calculate VPP core's load. I completely understand about the
> polling cores' 100% CPU usage. My requirement is different where I need to
> calculate the core's load based on how much more PPS it can handle before a
> packet drop occurs in the queue.
>
>
>
> The vec/call is a good indicator of load, but it does not increase
> linearly with PPS. This is because of the VPP's self balancing behaviour
> where the cost per packet reduces as load increases. It would be a great
> help if anyone can point out factors to calculate load.
>
>
>
> Thanks and regards,
>
> Ramkumar Balu
>
>
>
>
>
> 
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18368): https://lists.fd.io/g/vpp-dev/message/18368
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-16 Thread bjeremy32
Nope… the math works out… nothing goes to 0… we are incrementing both IDLE and 
BUSY. The processing of the rx queue is counted toward IDLE… In a completely 
idle system, the cpu usage falls to 0… as traffic ramps up it will go further 
positive based on pps, and as it goes to idle again it will go down to 0…

 

 

From: Damjan Marion  
Sent: Wednesday, December 16, 2020 3:00 AM
To: bjerem...@gmail.com
Cc: Nick Zavaritsky ; ramukmar1...@gmail.com; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

 

 





On 16.12.2020., at 05:45, bjerem...@gmail.com <mailto:bjerem...@gmail.com>  
wrote:

 

What we did was to count clock cycles (timestamps) spent processing the nodes, 
call this busy, and count the clock cycles spent elsewhere, call this idle. And 
then simply output (busy/(busy + idle). We did this per thread and stored the 
calculations globally. We then outputted the calculations on the ‘vppctl show 
thread’ cli.

 

This doesnt make lot of sense. Each input node is spending cycles to process rx 
queue, and out of that processing there may be zero or non-zero packets. So in 
completelly idle system according to your math result will be far away from 0.

 





 

This created a nice cpu usage metric that seems pretty accurate for io and 
worker threads…

 

What do you mean by io threads?





We compared this to something like htop for the worker threads and its within 
~1%, the io cores seem the same as we can see the usage go to about 80-90% when 
we start dropping packets. We are able to calculate the approx. PPS for a given 
system configuration.

 

It actually wasn’t a lot of effort. I think only three files were touched. 1. A 
new header file o create the global data structure to hold the clock cycle 
counts and associated macros to init and update the structures. 2. Vlib/main.c 
to instrument the main loop and collect the busy/idle clock cycles 3. Vlib 
threads_cli.c as show threads fn was used to output the cpu usage per thread.

 

From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  mailto:vpp-dev@lists.fd.io> > On Behalf Of Nick Zavaritsky
Sent: Tuesday, December 15, 2020 1:38 PM
To: ramukmar1...@gmail.com <mailto:ramukmar1...@gmail.com> 
Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
Subject: Re: [vpp-dev] Core Load Calculation

 

We’ve been using flamegraphs quite successfully to see how much leeway is there.

 

Ex: 
https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg






On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io <http://lists.fd.io/>  
mailto:ramukmar1998=gmail@lists.fd.io> 
> wrote:
 

Hello All,

 

I'm trying to calculate VPP core's load. I completely understand about the 
polling cores' 100% CPU usage. My requirement is different where I need to 
calculate the core's load based on how much more PPS it can handle before a 
packet drop occurs in the queue.

 

The vec/call is a good indicator of load, but it does not increase linearly 
with PPS. This is because of the VPP's self balancing behaviour where the cost 
per packet reduces as load increases. It would be a great help if anyone can 
point out factors to calculate load.

 

Thanks and regards, 

Ramkumar Balu









 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18366): https://lists.fd.io/g/vpp-dev/message/18366
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-16 Thread Damjan Marion via lists.fd.io


> On 16.12.2020., at 05:45, bjerem...@gmail.com wrote:
> 
> What we did was to count clock cycles (timestamps) spent processing the 
> nodes, call this busy, and count the clock cycles spent elsewhere, call this 
> idle. And then simply output (busy/(busy + idle). We did this per thread and 
> stored the calculations globally. We then outputted the calculations on the 
> ‘vppctl show thread’ cli.

This doesnt make lot of sense. Each input node is spending cycles to process rx 
queue, and out of that processing there may be zero or non-zero packets. So in 
completelly idle system according to your math result will be far away from 0.


>
> This created a nice cpu usage metric that seems pretty accurate for io and 
> worker threads…

What do you mean by io threads?

> We compared this to something like htop for the worker threads and its within 
> ~1%, the io cores seem the same as we can see the usage go to about 80-90% 
> when we start dropping packets. We are able to calculate the approx. PPS for 
> a given system configuration.
>
> It actually wasn’t a lot of effort. I think only three files were touched. 1. 
> A new header file o create the global data structure to hold the clock cycle 
> counts and associated macros to init and update the structures. 2. 
> Vlib/main.c to instrument the main loop and collect the busy/idle clock 
> cycles 3. Vlib threads_cli.c as show threads fn was used to output the cpu 
> usage per thread.
>
> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  <mailto:vpp-dev@lists.fd.io>> On Behalf Of Nick Zavaritsky
> Sent: Tuesday, December 15, 2020 1:38 PM
> To: ramukmar1...@gmail.com <mailto:ramukmar1...@gmail.com>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] Core Load Calculation
>
> We’ve been using flamegraphs quite successfully to see how much leeway is 
> there.
>
> Ex: 
> https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg
>  
> <https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg>
> 
> 
> On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io <http://lists.fd.io/> 
>  <mailto:ramukmar1998=gmail@lists.fd.io>> wrote:
>
> Hello All,
>
> I'm trying to calculate VPP core's load. I completely understand about the 
> polling cores' 100% CPU usage. My requirement is different where I need to 
> calculate the core's load based on how much more PPS it can handle before a 
> packet drop occurs in the queue.
>
> The vec/call is a good indicator of load, but it does not increase linearly 
> with PPS. This is because of the VPP's self balancing behaviour where the 
> cost per packet reduces as load increases. It would be a great help if anyone 
> can point out factors to calculate load.
>
> Thanks and regards, 
> Ramkumar Balu
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18351): https://lists.fd.io/g/vpp-dev/message/18351
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-15 Thread bjeremy32
What we did was to count clock cycles (timestamps) spent processing the nodes, 
call this busy, and count the clock cycles spent elsewhere, call this idle. And 
then simply output (busy/(busy + idle). We did this per thread and stored the 
calculations globally. We then outputted the calculations on the ‘vppctl show 
thread’ cli.

 

This created a nice cpu usage metric that seems pretty accurate for io and 
worker threads… We compared this to something like htop for the worker threads 
and its within ~1%, the io cores seem the same as we can see the usage go to 
about 80-90% when we start dropping packets. We are able to calculate the 
approx. PPS for a given system configuration.

 

It actually wasn’t a lot of effort. I think only three files were touched. 1. A 
new header file o create the global data structure to hold the clock cycle 
counts and associated macros to init and update the structures. 2. Vlib/main.c 
to instrument the main loop and collect the busy/idle clock cycles 3. Vlib 
threads_cli.c as show threads fn was used to output the cpu usage per thread.

 

From: vpp-dev@lists.fd.io  On Behalf Of Nick Zavaritsky
Sent: Tuesday, December 15, 2020 1:38 PM
To: ramukmar1...@gmail.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

 

We’ve been using flamegraphs quite successfully to see how much leeway is there.

 

Ex: 
https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg





On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io 
mailto:ramukmar1998=gmail@lists.fd.io> 
> wrote:
 

Hello All,

 

I'm trying to calculate VPP core's load. I completely understand about the 
polling cores' 100% CPU usage. My requirement is different where I need to 
calculate the core's load based on how much more PPS it can handle before a 
packet drop occurs in the queue.

 

The vec/call is a good indicator of load, but it does not increase linearly 
with PPS. This is because of the VPP's self balancing behaviour where the cost 
per packet reduces as load increases. It would be a great help if anyone can 
point out factors to calculate load.

 

Thanks and regards, 

Ramkumar Balu






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18348): https://lists.fd.io/g/vpp-dev/message/18348
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-15 Thread Nick Zavaritsky
We’ve been using flamegraphs quite successfully to see how much leeway is there.

Ex: 
https://gist.githack.com/mejedi/d5d094df63faba66d413a677fcef26e3/raw/95294d36c4b180ba6741d793bf345041b00af48e/g.svg

On 15 Dec 2020, at 19:53, Ramkumar B via lists.fd.io 
 wrote:

Hello All,

I'm trying to calculate VPP core's load. I completely understand about the 
polling cores' 100% CPU usage. My requirement is different where I need to 
calculate the core's load based on how much more PPS it can handle before a 
packet drop occurs in the queue.

The vec/call is a good indicator of load, but it does not increase linearly 
with PPS. This is because of the VPP's self balancing behaviour where the cost 
per packet reduces as load increases. It would be a great help if anyone can 
point out factors to calculate load.

Thanks and regards,
Ramkumar Balu




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18346): https://lists.fd.io/g/vpp-dev/message/18346
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Core Load Calculation

2020-12-15 Thread Dave Barach
In rough terms, you can model vector size as a function of offered load [and 
graph trajectory / configured features] with three linear segments. 

 

*   Dead asleep – single-digit vector sizes
*   Keeping up – vector sizes up to the no-drop offered load
*   Hitting the wall – vector sizes from the keep-up max to 256

 

Each of the three segments has a different slope. 

 

You might: find the true no-drop rate vector size. Call that point 100%. Find 
the inflection point at the end of the “dead asleep” region. Call that point 
5%. Compute the slope of the “keeping up” region, verify with multiple 
measurements. 

 

At that point, you can construct a function (or lookup table) tuned for your 
specific application.

 

Of course, you can map vector sizes to reported load however you like. 

 

HTH... Dave

 

P.S. Beware of creating an FAA-approved (aircraft) fuel gauge, which makes one 
promise: when the tanks are empty, the gauge will read empty.

 

From: vpp-dev@lists.fd.io  On Behalf Of Ramkumar B
Sent: Tuesday, December 15, 2020 11:53 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Core Load Calculation

 

Hello All,

 

I'm trying to calculate VPP core's load. I completely understand about the 
polling cores' 100% CPU usage. My requirement is different where I need to 
calculate the core's load based on how much more PPS it can handle before a 
packet drop occurs in the queue.

 

The vec/call is a good indicator of load, but it does not increase linearly 
with PPS. This is because of the VPP's self balancing behaviour where the cost 
per packet reduces as load increases. It would be a great help if anyone can 
point out factors to calculate load.

 

Thanks and regards,

Ramkumar Balu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18345): https://lists.fd.io/g/vpp-dev/message/18345
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[vpp-dev] Core Load Calculation

2020-12-15 Thread Ramkumar B
Hello All,

I'm trying to calculate VPP core's load. I completely understand about the
polling cores' 100% CPU usage. My requirement is different where I need to
calculate the core's load based on how much more PPS it can handle before a
packet drop occurs in the queue.

The vec/call is a good indicator of load, but it does not increase linearly
with PPS. This is because of the VPP's self balancing behaviour where the
cost per packet reduces as load increases. It would be a great help if
anyone can point out factors to calculate load.

Thanks and regards,
Ramkumar Balu

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18344): https://lists.fd.io/g/vpp-dev/message/18344
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-