Inlined functions in network code

Inlined functions in network code

[Łukasz Czyż]

Hello

I implemented stateful IPv6-IPv4 NAT translator which works on top of
netfilter. It is fully functional now, I only have a doubt about
criterion when to declare function as inline. Should all functions
which are used during packet translation (so they may be called very
frequently) be inlined?

Translator is released under GPLv2 license. You can find more info
about it at http://czyzu.pl/xlat.html

Lukasz

Inlined functions in network code

[Mulyadi Santosa]

Hi :)

On Sat, Mar 10, 2012 at 01:41, ?ukasz Czy? <perlowy.dzem@gmail.com> wrote:
> Hello
>
> I implemented stateful IPv6-IPv4 NAT translator which works on top of
> netfilter. It is fully functional now,

congratulations! A nice achievement IMHO.... :) is it merged with
linux kernel mainline?

>I only have a doubt about
> criterion when to declare function as inline. Should all functions
> which are used during packet translation (so they may be called very
> frequently) be inlined?

perhaps network guys know better, but I think inlining as we all know,
prevent code path to do jumps. And that will code execution faster,
especially when it happen many many times (read: millions or more).
And likely they will stay at the same L1 i-cache or at least
nearby...so that's nice too :)

IIRC too, "jmp" will screw branch prediction and sometimes will make
pipeline stall.....So, all in all, it's a matter about speeding about
code path, especially fast path like what you do.

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Inlined functions in network code

[Łukasz Czyż]

>
> congratulations! A nice achievement IMHO.... :)
>

Thanks :)

>
> is it merged with linux kernel mainline?
>

No. I am not sure if it good enough to be merged, I would like to get
some opinions before I ask to add it to mainline.

>
> IIRC too, "jmp" will screw branch prediction and sometimes will make
> pipeline stall.....So, all in all, it's a matter about speeding about
> code path, especially fast path like what you do.
>

Generally I am aware about advantages of inlining, but I also read in
CodingStyle document about its disadvantages, that is where my
question came from :) Maybe I should ask about it on some other list?


Lukasz Czyz

Inlined functions in network code

[richard -rw- weinberger]

On Sat, Mar 10, 2012 at 11:50 AM, ?ukasz Czy? <perlowy.dzem@gmail.com> wrote:
> No. I am not sure if it good enough to be merged, I would like to get
> some opinions before I ask to add it to mainline.

Submit a patch to netdev/netfilter-devel and you'll get a review.

-- 
Thanks,
//richard

Inlined functions in network code

[Bernd Petrovitsch]

Hi!

On Sam, 2012-03-10 at 02:02 +0700, Mulyadi Santosa wrote:
[....]
> On Sat, Mar 10, 2012 at 01:41, ?ukasz Czy? <perlowy.dzem@gmail.com> wrote:
[....]
> >I only have a doubt about
> > criterion when to declare function as inline. Should all functions
> > which are used during packet translation (so they may be called very
> > frequently) be inlined?
> 
> perhaps network guys know better, but I think inlining as we all know,
> prevent code path to do jumps. And that will code execution faster,
> especially when it happen many many times (read: millions or more).
> And likely they will stay at the same L1 i-cache or at least
> nearby...so that's nice too :)
> 
> IIRC too, "jmp" will screw branch prediction and sometimes will make
> pipeline stall.....So, all in all, it's a matter about speeding about
> code path, especially fast path like what you do.

On the other hand, if a function is "large" and copied several times,
more RAM is used and we have more i-cache pressure. That obviously
doesn't hold for functions thta have one call site.

Apart from that, the "inline" keyword in C is a pure hint to the C
compiler and the C compiler is free to ignore it for whatever reason
(and the C compiler is free to inline functions without that keyword).

So the usual rules are:
a) avoid forward declaration: gcc inlines functions with one call site
   without an explicit "inline".
   Yes, there are exceptions to this rule.
b) mark all locally only used functions "static" (so that the compiler
   knows actually that it isn't called from another file)
c) functions with a loop, if() or switch() shouldn't be inlined anyways
   (except of rule a) of course - but that doesn't require an explicit
   "inline")

Basically just "inline" functions which are one-liners (or so) and you
would actually make a macro out of it and keep it for parameter type
checking as an inline function.

Posting the patches now to appropriate mailing-lists is the best and you
will get (very probably) feedback from more people - and the ones which
are expected to eventually accept the patches.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at