netdev - Re: [Patch net-next 02/13] ipv4: introduce tracepoint trace_ip_queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM_iQpV8c=mUW=jXi4AS6p+tF2qVKmSfGqWrX5iAHDS62brdXg@mail.gmail.com>
Date:   Mon, 9 Aug 2021 13:32:41 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Qitao Xu <qitao.xu@...edance.com>,
        Cong Wang <cong.wang@...edance.com>
Subject: Re: [Patch net-next 02/13] ipv4: introduce tracepoint trace_ip_queue_xmit()

On Fri, Aug 6, 2021 at 3:09 AM Eric Dumazet <eric.dumazet@...il.com> 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!