Thread (7 messages) 7 messages, 4 authors, 2012-08-30

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_NETFILTER

Its 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help