[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251028170554.3588ee28@kernel.org>
Date: Tue, 28 Oct 2025 17:05:54 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: YonglongLi <liyonglong@...natelecom.cn>
Cc: netdev@...r.kernel.org, edumazet@...gle.com, horms@...nel.org
Subject: Re: [PATCH net v2 1/2] net: ip: add drop reasons when handling ip
 fragments
On Tue, 28 Oct 2025 15:34:48 +0800 YonglongLi wrote:
> Hi Jakub,
> 
> Thank you for your response. I'm sorry for the late reply.
> My email system seems to have some issues, and I loss  your reply msg.
> I get your response information from web page: https://lore.kernel.org/netdev.
So you resent the patches again? Please learn to use the ML correctly.
Also, again the subject tag should be [PATCH net-next] here not net
> > FRAG_OUTPUT_FAILED means something failed in output so it'd be more
> > meaningful to figure out what failed there, instead of adding
> > a bunch of ${CALLER}_OUTPUT_FAILED  
> 
> The skb send failed in output() is frag skb, The skb droped outside of output() is the
> origin skb. I think if we want to get detail drop reason we can use kfree_skb_reason
> in output() (maybe anther patch set in future).
> In my opinion, drop reason of the origin skb outside of output() can be not so meaningfull.
Do you have practical examples of output() failing? Are they in any way
related to the skb being fragmented? My intuition is that they would
not be, hence the fragmentation is not very relevant.
If the output() failed because there's something _special_ about
fragmented datagrams -- I'd agree with you. So let's see some
examples..
-- 
pw-bot: cr
Powered by blists - more mailing lists
 
