I believe it was just ring that they cared about.
-Original Message-
From: Damjan Marion
Sent: Monday, October 25, 2021 11:08 AM
To: bjerem...@gmail.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Linking DPDK libs to plugins
Ok, i’m affraid that to implement this you will need to i
Hi Damjan,
Thanks for the reply
Here are the details:
1. We want to use only the rte_mempool infrastructure for lockless global
memory pools. We will not be using any mbuf infrastructure from dpdk
2. We want to use this infra across our multiple plugins
3. We want to be able to include rte_mem
Greetings,
Let me preface this by saying that I really do not know much about the CMake
utility. But I am trying to see if there is a way to make the DPDK libs
accessible to other plugins (aside from the dpdk plugin) that are in their
own project/subdirectory similar. I am working with v20.05 c
@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
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 a
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
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 taki
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: Ram
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 Ca
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
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 o
11 matches
Mail list logo
