> On Sep 13, 2019, at 12:41 PM, Christian Hopps <[email protected]> wrote: > > Signed PGP part > > >> On Sep 13, 2019, at 12:23 PM, Damjan Marion <[email protected]> wrote: >> >> >> >>> On 13 Sep 2019, at 18:15, Christian Hopps <[email protected]> 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. Thanks, Chris. > > I tried "perf record --call-graph fp" but the results seemed odd (e.g., I see > a tcp function symbol deep within a call-branch rooted in the dpdk crypto > device enqueue routine for the marvell mvsam cryptodev). > > The reason I have an expectation for this code to run w/o drops is that I've > successfully forwarded 10G using 1500 byte packets, bidirectionally (total > throughput of 20G) with the same HW, I would not expect creating and > encrypting empty packets using HW offload to be over 10x slower. :) > > Thanks, > Chris. > >
signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13980): https://lists.fd.io/g/vpp-dev/message/13980 Mute This Topic: https://lists.fd.io/mt/34128898/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
