Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14

Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14

[Herbert Xu]

Kris Katterjohn <kjak@ispwest.com> wrote:
> Another patch for net/core/filter.c by me. I merged __load_pointer() into
> load_pointer(). I don't see a point in having two seperate functions when
> both functions are really small and load_pointer() calls __load_pointer().
> Renamed the variable "k" to "offset" since that's what it is, and in
> skb_header_pointer() it's "offset".
> 
> This patch is a diff from kernel 2.6.14

This code path is performance-critical so you should benchmark your
changes.

In this particular case, __load_pointer is the unlikely case and
therefore it wasn't inlined.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14

[Kris Katterjohn]

I wasn't actually changing it to add performance, but to make the code look
cleaner. The new load_pointer() is virtually the same as having the seperate
functions that are currently there, but the code, I think, is "better looking".
If you look at the current net/core/filter.c and then my patched version, the
steps are done in the exact same order and same way, but all in that one
function.

That may sound silly, but I just kept looking at it and asking myself, "Why?"

Of course, one way may still out-perform the other.


Thanks


----- Original Message -----
From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
Sent: 11/2/2005 5:50:29 PM
To: kjak@users.sourceforge.net
Cc: jschlst@samba.org; torvalds@osdl.org; linux-kernel@vger.kernel.org; davem@davemloft.net; acme@ghostprotocols.net; netdev@vger.kernel.org
Subject: Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14

> Kris Katterjohn <kjak@ispwest.com> wrote:
> > Another patch for net/core/filter.c by me. I merged __load_pointer() into
> > load_pointer(). I don't see a point in having two seperate functions when
> > both functions are really small and load_pointer() calls __load_pointer().
> > Renamed the variable "k" to "offset" since that's what it is, and in
> > skb_header_pointer() it's "offset".
> > 
> > This patch is a diff from kernel 2.6.14
> 
> This code path is performance-critical so you should benchmark your
> changes.
> 
> In this particular case, __load_pointer is the unlikely case and
> therefore it wasn't inlined.
> 
> Cheers,
> -- 
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14

[Herbert Xu]

Kris Katterjohn <kjak@ispwest.com> wrote:
> I wasn't actually changing it to add performance, but to make the code look
> cleaner. The new load_pointer() is virtually the same as having the seperate
> functions that are currently there, but the code, I think, is "better looking".
> If you look at the current net/core/filter.c and then my patched version, the
> steps are done in the exact same order and same way, but all in that one
> function.

You've just changed an out-of-line function (__load_pointer) into an
inlined function.  There may be a cost to that.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14

[Kris Katterjohn]

Forgive me because this is one of my first attempts at anything related to the
kernel, but...

1) How would I go about benchmarking this?
2) If the out-of-line code is executed anyway (since load_pointer() calls __load_pointer()),
would it really effect it very much?

I've been programming as a hobby for a few years, but I never really worried
about inlining my code. Most likely because when I was learning C, I was using
books etc. that were written before C99 was out.

Thanks


----- Original Message -----
From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
Subject: Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
> Kris Katterjohn <kjak@ispwest.com> wrote:
> > I wasn't actually changing it to add performance, but to make the code look
> > cleaner. The new load_pointer() is virtually the same as having the seperate
> > functions that are currently there, but the code, I think, is "better looking".
> > If you look at the current net/core/filter.c and then my patched version, the
> > steps are done in the exact same order and same way, but all in that one
> > function.
> 
> You've just changed an out-of-line function (__load_pointer) into an
> inlined function.  There may be a cost to that.
> -- 
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14

[Kris Katterjohn]

> From: Mitchell Blank Jr
> Cc:
> herbert@gondor.apana.org.au;jschlst@samba.org;davem@davemloft.net;
> acme@ghostprotocols.net;netdev@vger.kernel.org
> 
> > (I trimmed the cc: list a bit; no need for this to be on LKML in my opinion)
> > 
> > Kris Katterjohn wrote:
> > > Forgive me because this is one of my first attempts at anything related to the
> > > kernel, but...
> > > 
> > > 1) How would I go about benchmarking this?
> > 
> > The first thing to do is run "size net/core/filter.o" before and after and
> > see if your change makes the "text" section larger.
> > 
> > The risk of putting more stuff into the inlined function is just that
> > the rarely-executed path will end up duplicated in a bunch of places, bloating
> > the generated code.  It's hard to directly benchmark the effects of this but
> > it will generally make the fast-path code less compact in the L1 I-cache
> > which (if you do it enough) slows everything down.  Thats one reason why
> > kernel developers try to keep a close eye on bloat.
> > 
> > -Mitch
> 
> Before patch:
> 
>    text	   data	    bss	    dec	    hex	filename
>    2399	      0	      0	   2399	    95f	x/net/core/filter.o
> 
> After patch:
> 
>    text	   data	    bss	    dec	    hex	filename
>    2589	      0	      0	   2589	    a1d	y/net/core/filter.o
> 
> After patch without inlining the function:
> 
>    text	   data	    bss	    dec	    hex	filename
>    2127	      0	      0	   2127	    84f	y/net/core/filter.o
> 
> 
> So I guess use my patch and take "inline" off? What do you think?
> 
> 
> Thanks
>

Here's the new patch. It's the same as the first one, just with "inline" removed.

Maybe "static" should be removed, too? Oh well.

---


--- x/net/core/filter.c	2005-10-27 19:02:08.000000000 -0500
+++ y/net/core/filter.c	2005-11-03 00:05:42.000000000 -0600
@@ -13,6 +13,8 @@
  * 2 of the License, or (at your option) any later version.
  *
  * Andi Kleen - Fix a few bad bugs and races.
+ * Kris Katterjohn - Merged __load_pointer() into load_pointer() and
+ *                   cleaned it up a little bit - 2005-11-01
  */
 
 #include <linux/module.h>
@@ -35,31 +37,27 @@
 #include <asm/uaccess.h>
 #include <linux/filter.h>
 
-/* No hurry in this branch */
-static void *__load_pointer(struct sk_buff *skb, int k)
+static void *load_pointer(struct sk_buff *skb, int offset,
+                          unsigned int size, void *buffer)
 {
 	u8 *ptr = NULL;
 
-	if (k >= SKF_NET_OFF)
-		ptr = skb->nh.raw + k - SKF_NET_OFF;
-	else if (k >= SKF_LL_OFF)
-		ptr = skb->mac.raw + k - SKF_LL_OFF;
+	if (offset >= 0)
+		return skb_header_pointer(skb, offset, size, buffer);
+
+	if (offset >= SKF_AD_OFF)
+		return NULL;
+
+	if (offset >= SKF_NET_OFF)
+		ptr = skb->nh.raw + offset - SKF_NET_OFF;
+
+	else if (offset >= SKF_LL_OFF)
+		ptr = skb->mac.raw + offset - SKF_LL_OFF;
 
 	if (ptr >= skb->head && ptr < skb->tail)
 		return ptr;
-	return NULL;
-}
 
-static inline void *load_pointer(struct sk_buff *skb, int k,
-                                 unsigned int size, void *buffer)
-{
-	if (k >= 0)
-		return skb_header_pointer(skb, k, size, buffer);
-	else {
-		if (k >= SKF_AD_OFF)
-			return NULL;
-		return __load_pointer(skb, k);
-	}
+	return NULL;
 }
 
 /**

Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14

[Mitchell Blank Jr]

Kris Katterjohn wrote:
> > From: Mitchell Blank Jr
> > > (I trimmed the cc: list a bit; no need for this to be on LKML in my opinion)

I see you just added it back.  Oh well.

> > So I guess use my patch and take "inline" off? What do you think?

Well the original author presumably thought that the fast-path of
load_pointer() was critical enough to keep inline (since it can be run many
times per packet)  So they made the deliberate choice of separating it
into two functions - one inline, one non-inline.

So my personal feeling is that the code is probably fine as it stands today.

> Maybe "static" should be removed, too? Oh well.

Uh, why?  It's clearly a file-local function.

-Mitch

Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14

[Patrick McHardy]

Mitchell Blank Jr wrote:
> Kris Katterjohn wrote:
> 
>>>So I guess use my patch and take "inline" off? What do you think?
> 
> Well the original author presumably thought that the fast-path of
> load_pointer() was critical enough to keep inline (since it can be run many
> times per packet)  So they made the deliberate choice of separating it
> into two functions - one inline, one non-inline.

Exactly. __load_pointer is only called rarely, while load_pointer is
called whenever data needs to be read from the packet. It shouldn't
be changed without any justification.

Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c;kernel 2.6.14

[Kris Katterjohn]

From: Patrick McHardy
> Mitchell Blank Jr wrote:
> > Well the original author presumably thought that the fast-path of
> > load_pointer() was critical enough to keep inline (since it can be run many
> > times per packet)  So they made the deliberate choice of separating it
> > into two functions - one inline, one non-inline.
> 
> Exactly. __load_pointer is only called rarely, while load_pointer is
> called whenever data needs to be read from the packet. It shouldn't
> be changed without any justification.


That's a good enough answer for me!


Thanks