[ovs-dev] [PATCH 05/10] lib: inline miniflow trivial functions.

Ben Pfaff blp at nicira.com
Wed Nov 26 00:32:02 UTC 2014


On Thu, Nov 20, 2014 at 04:42:52PM -0800, Jarno Rajahalme wrote:
> miniflow_clone_inline(), miniflow_destroy(), miniflow_expand(),
> miniflow_get(), miniflow_equal(), minimask_init(), minimask_clone(),
> minimask_move(), minimask_destroy(), minimask_expand(),
> minimask_expand, minimask_get(), minimask_equal(),
> minimask_has_extra(), minimatch_init(), minimatch_clone(),
> minimatch_move, minimatch_destroy(), minimatch_expand(),
> minimatch_equal(), and minimatch_matches_flow() are inlined.  Many of
> these call each other, so inlining could be beneficial.
> 
> miniflow_equal_in_minimask() is moved to lib/classifier, which is the
> sole user of it.
> 
> miniflow_equal_flow_in_minimask() is moved to tests/test-classifier,
> which is the only user of it.

Some of these definitions are fairly large.  I wonder whether it's
time to start making use of the GNU C "extern inline" feature,
described in the GCC manual:

     If you specify both `inline' and `extern' in the function
    definition, then the definition is used only for inlining.  In no
    case is the function compiled on its own, not even if you refer to
    its address explicitly.  Such an address becomes an external
    reference, as if you had only declared the function, and had not
    defined it.

     This combination of `inline' and `extern' has almost the effect
    of a macro.  The way to use it is to put a function definition in
    a header file with these keywords, and put another copy of the
    definition (lacking `inline' and `extern') in a library file.  The
    definition in the header file will cause most calls to the
    function to be inlined.  If any uses of the function remain, they
    will refer to the single copy in the library.

What do you think?



More information about the dev mailing list