> On 13 Sep 2019, at 18:58, Christian Hopps <cho...@chopps.org> wrote: > > > >> On Sep 13, 2019, at 12:41 PM, Christian Hopps <cho...@chopps.org> wrote: >> >> Signed PGP part >> >> >>> On Sep 13, 2019, at 12:23 PM, Damjan Marion <dmar...@me.com> wrote: >>> >>> >>> >>>> On 13 Sep 2019, at 18:15, Christian Hopps <cho...@chopps.org> wrote: >>>> >>>> Is it possible to profile vpp with gprof? >>> >>> What exactly do you want to profile? Can you describe your use case? >> >> Trying to figure out why my code is not running as fast as it should. :) >> >> The code is currently pretty straight-forward: >> >> - main thread (0) is on a core (3) >> - send thread (1, worker 0) is on core 0 >> - receive thread (2, worker 1) is on core 1. >> - processing thread (3 worker 2) is on core 2, and is not doing anything >> right now. >> >> Operation: >> >> - The send code is sending encrypted (using cryptodev mvsam) fixed sized >> (1500b) empty packets (i.e., the data is just whatever is there when I >> advance current_length of the buffer). >> >> - The receive code is decrypting (again using cryptodev mvsam) these packes >> and doing a hand-off to the processing thread which does nothing with them. >> The drops are detected using ESP sequence number, prior to doing the >> hand-off -- IOW that's all my code is doing other than the hand off >> post-decrypt. >> >> I'm sending on fixed intervals to achieve a throughput of 1Ghz (so 83333pps >> spaced 12000ns apart). I'm currently seeing dropped packets (either inbound >> or outbound as yet to be determined) and many missed send slots in my >> polling (sending) routine. > > I should note, I don't mind if these packets are clumped together as long as > the average is 83333pps, so the send routine is written to send as many as it > should even when it misses it's send slot[s] thus using the standard vector > of packets design of vpp. However, currently I'm even not bothering to > catch-up when I miss sending these empty packets for missed timing slots, so > the performance is even worse than it seems at first glance -- this not > sending isn't a drop though it's just sending less often.
Are you aware that if there is no rx interfaces in polling mode (or any other input node in polling mode) assigned to specific worker, then that worker will end up sleeping in epoll_wait() for 10msec? May that be cause of your problem?
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13989): https://lists.fd.io/g/vpp-dev/message/13989 Mute This Topic: https://lists.fd.io/mt/34128898/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
