Inlined functions in network code
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
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
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
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
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@petrovitsch.priv.at LUGA : http://www.luga.at
participants (4)
-
Bernd Petrovitsch -
Mulyadi Santosa -
richard -rw- weinberger -
Łukasz Czyż