Hi Andreas, I think you are right about the stop-world way it works.
We have seen a performance impact, but that was for a command that was quite slow, listing something with many lines of output (the "show nat44 sessions" command). So then the worker threads were stopped during that whole operation and we saw some packet drops each time. Later we were able to extract the info we needed in other ways (like getting number of sessions directly as a single number per thread via the python API instead of fetching a large output and counting lines in that), so we could avoid that performance problem. For small things like checking the values of some counters, we have not seen any performance impact. But then we only did those calls once every 30 seconds or so. If you do it very often, like many times times per second, maybe there could be a performance impact also for small things. I suppose you could test it by gradually increasing the frequency of your API calls and seeing when drops start to happen. Best regards, Elias On Wed, 2020-03-11 at 17:03 +0100, Andreas Schultz wrote: > Hi, > > Has anyone benchmarked the impact of VPP API invocations on the > forwarding performance? > > Background: most calls on the VPP API run in a stop-world maner. That > means all graph node worker threads are stopped at a barrier, the API > call is executed and then the workers are released from the barrier. > Right? > > My question is now, when I do 1k, 10k or even 100k API invocation per > second, how does that impact the forwarding performance of VPP? > > Does anyone have a use-case running that is actually doing that? > > Many thanks, > Andreas
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15738): https://lists.fd.io/g/vpp-dev/message/15738 Mute This Topic: https://lists.fd.io/mt/71882379/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
