> 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?
>> 
>> I google a bit but I'm not turning anything up. I have made some build 
>> changes to compile/link with -pg (starting with the gcov target), and a 
>> change to not handle SIGPROF. This produced a binary that created a gmon.out 
>> file. That file only has some info on the main thread though. I've read I 
>> may need to also set an itimer (although other things I read said this 
>> should be handled since 2014).
>> 
>> Has anyone else succeeded in doing this with vpp?
> 
> 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 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.

Attachment: signature.asc
Description: Message signed with OpenPGP

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13979): https://lists.fd.io/g/vpp-dev/message/13979
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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to