Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <8f6d5115-1158-7276-b991-31253476326b@kernel.org>
Date:   Wed, 16 Mar 2022 15:05:23 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.2
Subject: Re: [PATCH net-next 1/3] net: gre_demux: add skb drop reasons to
 gre_rcv()
Content-Language: en-US
To:     Jakub Kicinski <kuba@kernel.org>
Cc:     menglong8.dong@gmail.com, rostedt@goodmis.org, mingo@redhat.com,
        xeb@mail.ru, davem@davemloft.net, yoshfuji@linux-ipv6.org,
        imagedong@tencent.com, edumazet@google.com, kafai@fb.com,
        talalahmad@google.com, keescook@chromium.org, alobakin@pm.me,
        flyingpeng@tencent.com, mengensun@tencent.com,
        dongli.zhang@oracle.com, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, Biao Jiang <benbjiang@tencent.com>
References: <20220314133312.336653-1-imagedong@tencent.com>
 <20220314133312.336653-2-imagedong@tencent.com>
 <20220315200847.68c2efee@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
 <daa287f3-fbed-515d-8f37-f2a36234cc8a@kernel.org>
 <20220315215553.676a5d24@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
 <30b0991a-8c41-2571-b1b6-9edc7dc9c702@kernel.org>
 <20220316115734.1899bb11@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
From:   David Ahern <dsahern@kernel.org>
In-Reply-To: <20220316115734.1899bb11@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/16/22 12:57 PM, Jakub Kicinski wrote:
> On Wed, 16 Mar 2022 08:56:14 -0600 David Ahern wrote:
>>> That's certainly true. I wonder if there is a systematic way of
>>> approaching these additions that'd help us picking the points were 
>>> we add reasons less of a judgment call.  
>>
>> In my head it's split between OS housekeeping and user visible data.
>> Housekeeping side of it is more the technical failure points like skb
>> manipulations - maybe interesting to a user collecting stats about how a
>> node is performing, but more than likely not. IMHO, those are ignored
>> for now (NOT_SPECIFIED).
>>
>> The immediate big win is for packets from a network where an analysis
>> can show code location (instruction pointer), user focused reason (csum
>> failure, 'otherhost', no socket open, no socket buffer space, ...) and
>> traceable to a specific host (headers in skb data).
> 
> Maybe I'm oversimplifying but would that mean first order of business
> is to have drop codes for where we already bump MIB exception stats?

That was the original motivation and it has since spun out of control -
walking the code base and assigning unique drop reasons for every single
call to kfree_skb.