Processing at User-Level

Onload User Guide (UG1586)

Document ID
Release Date
1.2 English

Many applications can achieve better performance when most processing occurs at user-level rather than kernel-level. To identify how an application is performing, enter the following command:

onload_stackdump lots | grep polls
Table 1. Onload_stackdump Polling Counters
Counter Description
k_polls Number of times the socket event queue was polled from the kernel.
u_polls Number of times the socket event queue was polled from user space.
periodic_polls Number of times a periodic timer has polled for events.
interrupt_polls Number of times an interrupt polled for network events.
deferred_polls Number of times poll has been deferred to the stack lock holder.
timeout_interrupt_polls Number of times timeout interrupts polled for network events.
$ onload_stackdump lots | grep poll k_polls: 673 u_polls: 41

The output identifies many more k_polls than u_polls indicating that the stack is operating mainly at kernel-level and might not be achieving optimal performance. A possible cause is that application logic is taking longer than EF_POLL_USEC.


Terminate the application and set the EF_POLL_USEC parameter to 100000. Restart the application and re-run onload_stackdump:

export EF_POLL_USEC=100000 onload_stackdump lots | grep polls$ onload_stackdump lots | grep polls k_polls: 673 u_polls: 1289

The output identifies that the number of u_polls is far greater than the number of k_polls indicating that the stack is now operating mainly at user-level.

For more information see Spinning, Polling and Interrupts.