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 at 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