Re: [vpp-dev] impact of API requests on forwarding performance?
Hi Elias,
> Thanks for explaining!
> I'm sorry if what I wrote before was wrong or confusing.
no, not at all!
>> Checking counters values in the stats segment has _no_ impact on VPP.
>> VPP writes those counters regardless of reader frequency.
>
> That's great!
>
> Just to be clear, to make sure I understand what this means, if we do
> the following in python:
>
> from vpp_papi.vpp_stats import VPPStats
> stat = VPPStats("/run/vpp/stats.sock")
> dir = stat.ls(['^/nat44/total-users'])
> counters = stat.dump(dir)
> list_of_counters=counters.get('/nat44/total-users')
>
> (followed by a loop in python to sum up the counter values from
> different vpp threads) then what we are doing is that we are checking
> counters values in the stats segment, so there should be no impact on
> VPP?
Yes, that is correct.
(Of course depending on how pedantic you want to be there is an extra load on
the memory hierarchy by client reading, which may in turn affect VPP.)
The actual VPP counter is exposed directly in shared memory. No copying or
locking from VPP side.
The client uses optimistic locking, meaning that it will retry copying out the
counter if the underlaying stat segment directory structure has changed.
Best regards,
Ole-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15748): https://lists.fd.io/g/vpp-dev/message/15748
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]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] impact of API requests on forwarding performance?
Hi Ole,
Thanks for explaining!
I'm sorry if what I wrote before was wrong or confusing.
> Checking counters values in the stats segment has _no_ impact on VPP.
> VPP writes those counters regardless of reader frequency.
That's great!
Just to be clear, to make sure I understand what this means, if we do
the following in python:
from vpp_papi.vpp_stats import VPPStats
stat = VPPStats("/run/vpp/stats.sock")
dir = stat.ls(['^/nat44/total-users'])
counters = stat.dump(dir)
list_of_counters=counters.get('/nat44/total-users')
(followed by a loop in python to sum up the counter values from
different vpp threads) then what we are doing is that we are checking
counters values in the stats segment, so there should be no impact on
VPP?
Best regards,
Elias
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15743): https://lists.fd.io/g/vpp-dev/message/15743
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]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] impact of API requests on forwarding performance?
Elias, > 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. The correct answer is of course "it depends". Non thread safe API calls will block the workers. Thread-safe ones, may incur locking that affects the workers. The dump/detail mechanism is not suitable to dump large data structures. Those typically would block the main thread for too long a time. In general the expectation is that the control plane should know what it has confiured VPP with, so there shouldn't be a need to query VPP for that information. For frequently changing data structures like the NAT binding table, it's a little trickier. The NAT binding table could have several hundred million entries with millions of adds/deletes a second. Neither the stats segment or the API is useful for that. Although you could imagine doing something with snap-shots. For data structures like that there is ipfix or even syslog. > 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. Checking counters values in the stats segment has _no_ impact on VPP. VPP writes those counters regardless of reader frequency. Best regards, Ole-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15740): https://lists.fd.io/g/vpp-dev/message/15740 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] impact of API requests on forwarding performance?
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] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] impact of API requests on forwarding performance?
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 -- Andreas Schultz -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15729): https://lists.fd.io/g/vpp-dev/message/15729 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] -=-=-=-=-=-=-=-=-=-=-=-
