Using Onload Tuning Profiles

Onload User Guide (UG1586)

Document ID
Release Date
1.2 English

Environment variables set in the application user-space can be used to configure and control aspects of the accelerated application’s performance. These variables can be exported using the Linux export command. For example:

export EF_POLL_USEC=100000

Onload supports tuning profile script files which are used to group environment variables within a single file to be called from the Onload command line.

The latency profile sets the EF_POLL_USEC=100000 setting the busy-wait spin timeout to 100 milliseconds. The profile also disables TCP faststart for new or idle connections where additional TCP ACKs will add latency to the receive path. To use the profile include it on the onload command line. For example:

onload --profile=latency netperf -H onload2-sfc -t TCP_RR

Following Onload installation, the profiles that it provides are located in the following directory - this directory will be deleted by the onload_uninstall command:


User-defined environment variables can be written to a user-defined profile script file (having a .opf extension) and stored in any directory on the server. The full path to the file should then be specified on the onload command line. For example:

onload --profile=/tmp/myprofile.opf netperf -H onload2-sfc -t TCP_RR

As an example the latency profile, provided by the Onload distribution is shown below:

# Onload low latency profile.
# Enable polling / spinning. When the application makes a blocking call
# such as recv() or poll(), this causes Onload to busy wait for up to 100ms
# before blocking.
onload_set EF_POLL_USEC=100000
# Disable FASTSTART when connection is new or has been idle for a while.
# The additional acks it causes add latency on the receive path.

For a complete list of environment variables refer to Parameter Reference.

The latency-best Profile

The latency-best profile targets the lowest possible latency for a given release of Onload. This means that:

  • Some features used in the profile might be experimental.
  • The combination of features in the profile might not be suitable for all deployments, or all types of traffic.
  • The profile is subject to change between releases.

    As new low-latency features become available, they will be added to the profile.

Consequently, the following is recommended:

  • Always create a renamed copy of the profile, and use the copy.

    This will avoid the profile unexpectedly changing when you update Onload, and potentially breaking your applications.

  • Always test and tune your copy of the profile in a non-production environment, before deploying it.

    This will avoid issues caused by combinations of settings that are inappropriate for your production systems.

Important: If you do not follow the above recommendations, and directly use the latency-best profile in a production environment, you might experience issues either now, or when upgrading Onload in the future.

The nginx_reverse_proxy Profile

Onload's clustering capability has been extended to provide better support for the NGINX application's master process pattern and hot restart operation by correctly associating Onload stacks and application worker processes. To do so, the following settings are used:

EF_CLUSTER_HOT_RESTART:               1


A new nginx_reverse_proxy profile has an example set of relevant configurations, including further settings. This profile searches for the NGINX configuration file, and then uses the settings from that file to make the correct Onload settings. Similar techniques can be used to make profiles that target other applications.

Note: Use of this profile is not compatible with use of the onload extensions stackname API.