Thanks Klement. I believe the problem is the slow app (service C) with very low pps bringing down pps in VPP. I am wondering if there is a way to tune VPP dispatcher timing so that it will dispatch packets at a slower packet rate/pps which hopefully could increase the vector size.
Thank you - Pranab K Das On Fri, Nov 19, 2021 at 5:07 AM Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco) <ksek...@cisco.com> wrote: > Hey, > > Efficiency increases (a lot) with vector size, so pondering packet rates > at low sizes doesn’t make much sense. Looking at vector size, you can tell > how loaded VPP is. At your vector size, VPP is slacking off and efficiency > is thus low, but it doesn’t matter, because you are not processing enough > packets to care (on your particular box). To see real limits, you could > increase the packet rate until you start seeing drops, then ease of bit by > bit until it’s stable with no drops. You will see vector size being close > to or at 255. Note that at these rates, any preemption from OS or other > apps will cause packet drops, so it’s best to dedicate cores to VPP > exclusively and tune the system for minimum latency. Function of vector > size/packet rate is indeed non-linear and I don’t think there is a simple > formula to calculate it. > > Of course don’t forget to do (while under load): > > clear run > <wait a while> > show run > > to see real numbers. > > HTH, > Klement > > > On 19 Nov 2021, at 02:10, PRANAB DAS <pkdas.bos...@gmail.com> wrote: > > > > Hello all, > > > > IMHO primary motivation of using VPP as the name suggests is Vector > Packet Processing with the belief that it will maximize i-cache and d-cache > hit and thus will result in much higher pps and throughput than scalar > processing. > > > > Somehow I am finding the application we are running in VPP has very low > vector size < 10 with 40% cpu utilization. Does it mean we are not getting > the benefit of vector processing and we are doing something wrong? In what > conditions, will VPP function poorly meaning instead of vector processing > it ends up doing 2 or 3 packets per graph node - thus as scalar packet > processor? > > > > Basically the datapath application can be considered as a service chain > of 3 different application datapath services each having a different > performance profile. > > > > service A --->service B ----> serviceC > > > > service A is the fastest, most efficient can do 4Mpps > > service B is less can do 2Mpps > > service C can do 500Kpps > > > > service A and service B are running in VPP in different worker threads > and service C (DPDK based) running as another process. > > > > We scale out service C (add more cpu cores 4 time service B) and service > B has twice the number of VPP worker threads than service A > > > > Assuming we have 8 cores for service C, 2 VPP workers for service B and > 1 for service A - what kind of vector size do we expect when we try 4Mpps, > 2Mpps or 1Mpps (assuming NIC BW does not matter). > > > > I am arguing that in VPP performance is not linear, rather it depends on > vector size. Is that true? > > Is there any documentation on how to size or tune application > performance/vector size on VPP? > > > > I really appreciate your help. > > > > Thank you > > > > _ Pranab K Das > > > > > > > > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20525): https://lists.fd.io/g/vpp-dev/message/20525 Mute This Topic: https://lists.fd.io/mt/87158267/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
