I’d say that that’s quite pointless. If your vector size is small it means VPP
has a lot of headroom in your environment. Maybe take a look at config options
- there is one which catches my eye ‘unix {poll-sleep-usec}’ which might help
you get what you want at the cost of probably not being able to handle higher
packet rates.
You might also need to use CLI ’set interface rx-mode <interface> polling’ to
force polling all the time, as I think default is adaptive and at low rates it
doesn’t poll. However I think that by doing so, you’ll increase CPU usage :)
Klement
> On 22 Nov 2021, at 05:21, PRANAB DAS <pkdas.bos...@gmail.com> wrote:
>
> 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 (#20527): https://lists.fd.io/g/vpp-dev/message/20527
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]
-=-=-=-=-=-=-=-=-=-=-=-
