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 <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] -=-=-=-=-=-=-=-=-=-=-=-