[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220302112255.545618dd@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date: Wed, 2 Mar 2022 11:22:55 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: David Ahern <dsahern@...il.com>
Cc: Dongli Zhang <dongli.zhang@...cle.com>, netdev@...r.kernel.org,
bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
davem@...emloft.net, rostedt@...dmis.org, mingo@...hat.com,
ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
imagedong@...cent.com, joao.m.martins@...cle.com,
joe.jin@...cle.com, edumazet@...gle.com
Subject: Re: [PATCH net-next v4 4/4] net: tun: track dropped skb via
kfree_skb_reason()
On Tue, 1 Mar 2022 20:29:37 -0700 David Ahern wrote:
> On 3/1/22 7:50 PM, Jakub Kicinski wrote:
> > On Sat, 26 Feb 2022 00:49:29 -0800 Dongli Zhang wrote:
> >> + SKB_DROP_REASON_SKB_PULL, /* failed to pull sk_buff data */
> >> + SKB_DROP_REASON_SKB_TRIM, /* failed to trim sk_buff data */
> >
> > IDK if these are not too low level and therefore lacking meaning.
> >
> > What are your thoughts David?
>
> I agree. Not every kfree_skb is worthy of a reason. "Internal
> housekeeping" errors are random and nothing a user / admin can do about
> drops.
>
> IMHO, the value of the reason code is when it aligns with SNMP counters
> (original motivation for this direction) and relevant details like TCP
> or UDP checksum mismatch, packets for a socket that is not open, socket
> is full, ring buffer is full, packets for "other host", etc.
Agreed :(
Powered by blists - more mailing lists