[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YdOnTcSBq8z961da@pop-os.localdomain>
Date: Mon, 3 Jan 2022 17:47:57 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: menglong8.dong@...il.com
Cc: rostedt@...dmis.org, dsahern@...nel.org, mingo@...hat.com,
davem@...emloft.net, kuba@...nel.org, nhorman@...driver.com,
edumazet@...gle.com, yoshfuji@...ux-ipv6.org,
jonathan.lemon@...il.com, alobakin@...me, keescook@...omium.org,
pabeni@...hat.com, talalahmad@...gle.com, haokexin@...il.com,
imagedong@...cent.com, atenart@...nel.org, bigeasy@...utronix.de,
weiwan@...gle.com, arnd@...db.de, vvs@...tuozzo.com,
cong.wang@...edance.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, mengensun@...cent.com,
mungerjiang@...cent.com
Subject: Re: [PATCH v2 net-next 0/3] net: skb: introduce
kfree_skb_with_reason() and use it for tcp and udp
On Thu, Dec 30, 2021 at 05:32:37PM +0800, menglong8.dong@...il.com wrote:
> From: Menglong Dong <imagedong@...cent.com>
>
> In this series patch, the interface kfree_skb_with_reason() is
> introduced(), which is used to collect skb drop reason, and pass
> it to 'kfree_skb' tracepoint. Therefor, 'drop_monitor' or eBPF is
> able to monitor abnormal skb with detail reason.
>
We already something close, __dev_kfree_skb_any(). Can't we unify
all of these?
> In fact, this series patches are out of the intelligence of David
> and Steve, I'm just a truck man :/
>
I think there was another discussion before yours, which I got involved
as well.
> Previous discussion is here:
>
> https://lore.kernel.org/netdev/20211118105752.1d46e990@gandalf.local.home/
> https://lore.kernel.org/netdev/67b36bd8-2477-88ac-83a0-35a1eeaf40c9@gmail.com/
>
> In the first patch, kfree_skb_with_reason() is introduced and
> the 'reason' field is added to 'kfree_skb' tracepoint. In the
> second patch, 'kfree_skb()' in replaced with 'kfree_skb_with_reason()'
> in tcp_v4_rcv(). In the third patch, 'kfree_skb_with_reason()' is
> used in __udp4_lib_rcv().
>
I don't follow all the discussions here, but IIRC it would be nice
if we can provide the SNMP stat code (for instance, TCP_MIB_CSUMERRORS) to
user-space, because those stats are already exposed to user-space, so
you don't have to invent new ones.
Thanks.
Powered by blists - more mailing lists