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
Thanks
Signed-off-by: Kris Katterjohn <[email protected]>
---
--- x/net/core/filter.c 2005-10-27 19:02:08.000000000 -0500
+++ y/net/core/filter.c 2005-11-02 02:05:40.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 inline 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;
}
/**
Kris Katterjohn <[email protected]> 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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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:[email protected]]
Sent: 11/2/2005 5:50:29 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
> Kris Katterjohn <[email protected]> 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~} <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Kris Katterjohn <[email protected]> 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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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:[email protected]]
Subject: Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
> Kris Katterjohn <[email protected]> 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~} <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Mitchell Blank Jr
> > 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
> From: Mitchell Blank Jr
> Cc:
> [email protected];[email protected];[email protected];
> [email protected];[email protected]
>
> > (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;
}
/**
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
> > > 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.
When I emailed (CC:) Herbert Xu (who emailed about this earlier), I got an email
back that said it couldn't send to him. So, I just added linux-kernel back so
he'd see it if he's interested at all.
> > > 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.
It probably is. Doesn't really matter I guess.
> > Maybe "static" should be removed, too? Oh well.
>
> Uh, why? It's clearly a file-local function.
No real reason, just that none of the other functions in filter.c are static.
Thanks
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.