[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALOAHbDgfcc9XPmsw=2KkBQs4EUOQHH4dFVC=zGMfxfFDAEa-Q@mail.gmail.com>
Date: Fri, 25 Oct 2024 13:58:33 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: Daniel Xu <dxu@...uu.xyz>
Cc: Eric Dumazet <edumazet@...gle.com>, David Miller <davem@...emloft.net>, dsahern@...nel.org,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
Menglong Dong <menglong8.dong@...il.com>
Subject: Re: [PATCH 2/2] net: tcp: Add noinline_for_tracing annotation for tcp_drop_reason()
On Fri, Oct 25, 2024 at 4:57 AM Daniel Xu <dxu@...uu.xyz> wrote:
>
> Hi Yafang,
>
> On Thu, Oct 24, 2024, at 2:37 AM, Yafang Shao wrote:
> > We previously hooked the tcp_drop_reason() function using BPF to monitor
> > TCP drop reasons. However, after upgrading our compiler from GCC 9 to GCC
> > 11, tcp_drop_reason() is now inlined, preventing us from hooking into it.
> > To address this, it would be beneficial to make noinline explicitly for
> > tracing.
>
> It looks like kfree_skb() tracepoint has rx_sk field now. Added in
> c53795d48ee8 ("net: add rx_sk to trace_kfree_skb").
This commit is helpful. Thank you for providing the information. I
plan to backport it to our local kernel.
>
> Between sk and skb, is there enough information to monitor TCP drops?
> Or do you need something particular about tcp_drop_reason()?
There's nothing else specific to mention. The @rx_sk introduced in the
commit you referred to will be beneficial to us.
BTW, it would be fantastic if we could trace inline functions.
Additionally, can your feature[0] also allow for live patching of
inline functions?
[0] https://x.com/__dxu/status/1849271647989068107
--
Regards
Yafang
Powered by blists - more mailing lists