Re: [PATCH] skbuff: remove pointless conditional before kfree_skb()
From: Eric Dumazet <hidden>
Date: 2012-08-28 20:09:59
On Tue, 2012-08-28 at 16:17 -0300, Flavio Leitner wrote:
On Tue, 28 Aug 2012 07:12:34 -0700 Eric Dumazet [off-list ref] wrote:quoted
On Tue, 2012-08-28 at 21:10 +0800, Wei Yongjun wrote:quoted
From: Wei Yongjun <redacted> Remove pointless conditional before kfree_skb(). Signed-off-by: Wei Yongjun <redacted> --- include/linux/skbuff.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 7632c87..0b846d9 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h@@ -2464,8 +2464,7 @@ static inline void nf_conntrack_get_reasm(struct sk_buff *skb) } static inline void nf_conntrack_put_reasm(struct sk_buff *skb) { - if (skb) - kfree_skb(skb); + kfree_skb(skb); } #endif #ifdef CONFIG_BRIDGE_NETFILTERIts not exactly pointless. Its a tradeoff between kernel code size, and ability for cpu to predict a branch in kfree_skb() This test is in hot path, and therefore this patch can potentially have a performance impact. I really think most kfree_skb() calls are done with a non NULL param, so the branch prediction is good. But after this patch, things are totally different.But then the kfree_skb() is somewhat misleading because it does check for NULL argument. One would have to remember if it's in hot path or not. So, what about a new macro to pair with kfree_skb()? That would document the code and would also make easier to remember about the performance issue. For instance: /* kfree_skb() version to be used in hot code path * as the branch prediction can improve performance */ #define kfree_skb_hot(skb) \ if (skb) \ kfree_skb(skb) \
Really kfree_skb() is not misleading at all : if (unlikely(!skb)) return; So while its _perfectly_ valid to call kfree_skb(NULL), this code expect callers to not abuse this facility. And nf_conntrack_put_reasm() is called from skb_release_head_state() We know in this code that most of the time, skb will be NULL. I dont think we need to add another API for this case and see one hundred patches coming _trying_ to use this new API. Just review patches and shout if something bad happens.