Re: [Patch net-next 02/13] ipv4: introduce tracepoint trace_ip_queue_xmit()

On Fri, Aug 6, 2021 at 3:09 AM Eric Dumazet [off-list ref] wrote:

While it is useful to have stuff like this,
ddding so many trace points has a certain cost.

I fear that you have not determined this cost
on workloads where we enter these functions with cold caches.

For instance, before this patch, compiler gives us :

2e10 <ip_queue_xmit>:
    2e10:       e8 00 00 00 00          callq  2e15 <ip_queue_xmit+0x5> (__fentry__-0x4)
    2e15:       0f b6 8f 1c 03 00 00    movzbl 0x31c(%rdi),%ecx
    2e1c:       e9 ef fb ff ff          jmpq   2a10 <__ip_queue_xmit>


After patch, we see the compiler had to save/restore registers, and no longer
jumps to __ip_queue_xmit. Code is bigger, even when tracepoint is not enabled.

Interesting, I didn't pay attention to the binary code generated
by compilers. Let me check it, as I have moved the trace function
before __ip_queue_xmit() (otherwise the order is reversed).

Thanks!