[ovs-build] Broken: istokes/ovs#930 (dpcl_func_ptr - 70a09e2)

Travis CI builds at travis-ci.org
Thu Jul 18 09:05:48 UTC 2019


Build Update for istokes/ovs
-------------------------------------

Build: #930
Status: Broken

Duration: 3 mins and 9 secs
Commit: 70a09e2 (dpcl_func_ptr)
Author: Harry van Haaren
Message: dpif-netdev: Add specialized generic scalar functions

This commit adds a number of specialized functions, that handle
common miniflow fingerprints. This enables compiler optimization,
resulting in higher performance. Below a quick description of
how this optimization actually works;

"Specialized functions" are "instances" of the generic implementation,
but the compiler is given extra context when compiling. In the case of
iterating miniflow datastructures, the most interesting value to enable
compile time optimizations is the loop trip count per unit.

In order to create a specialized function, there is a generic implementation,
which uses a for() loop without the compiler knowing the loop trip count at
compile time. The loop trip count is passed in as an argument to the function:

uint32_t miniflow_impl_generic(struct miniflow *mf, uint32_t loop_count)
{
    for(uint32_t i = 0; i < loop_count; i++)
        // do work
}

In order to "specialize" the function, we call the generic implementation
with hard-coded numbers - these are compile time constants!

uint32_t miniflow_impl_loop5(struct miniflow *mf, uint32_t loop_count)
{
    // use hard coded constant for compile-time constant-propogation
    return miniflow_impl_generic(mf, 5);
}

Given the compiler is aware of the loop trip count at compile time,
it can perform an optimization known as "constant propogation". Combined
with inlining of the miniflow_impl_generic() function, the compiler is
now enabled to *compile time* unroll the loop 5x, and produce "flat" code.

The last step to using the specialized functions is to utilize a
function-pointer to choose the specialized (or generic) implementation.
The selection of the function pointer is performed at subtable creation
time, when miniflow fingerprint of the subtable is known. This technique
is known as "multiple dispatch" in some literature, as it uses multiple
items of information (miniflow bit counts) to select the dispatch function.

By pointing the function pointer at the optimized implementation, OvS
benefits from the compile time optimizations at runtime.

Signed-off-by: Harry van Haaren <harry.van.haaren at intel.com>
Tested-by: Malvika Gupta <malvika.gupta at arm.com>
Signed-off-by: Ian Stokes <ian.stokes at intel.com>

View the changeset: https://github.com/istokes/ovs/compare/c80b5f966b3b...70a09e292538

View the full build log and details: https://travis-ci.org/istokes/ovs/builds/560165945?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the istokes/ovs repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=16644441&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-build/attachments/20190718/c28300e2/attachment-0001.html>


More information about the build mailing list