</ul>
</div>
+<div class="slide">
+ <h1>Network busy-polling [3.11] (1)</h1>
+ <p>A conventional network request/response process looks like:</p>
+ <small><!-- ew -->
+ <ol class="incremental">
+ <li>
+ Task calls <tt>send()</tt>; network stack constructs a
+ packet; driver adds it to hardware Tx queue
+ </li>
+ <li>
+ Task calls <tt>poll()</tt> or <tt>recv()</tt>, which blocks;
+ kernel puts it to sleep and possibly idles the CPU
+ </li>
+ <li>
+ Network adapter receives response and generates IRQ, waking
+ up CPU
+ </li>
+ <li>
+ Driver's IRQ handler schedules polling of the hardware Rx
+ queue (NAPI)
+ </li>
+ <li>
+ Kernel runs the driver's NAPI poll function, which passes
+ the response packet into the network stack
+ </li>
+ <li>
+ Network stack decodes packet headers and adds packet to
+ the task's socket
+ </li>
+ <li>
+ Network stack wakes up sleeping task; scheduler switches
+ to it and the socket call returns
+ </li>
+ </ol>
+ </small>
+</div>
+
+<div class="slide">
+ <h1>Network busy-polling [3.11] (2)</h1>
+ <ul class="incremental">
+ <li>
+ If driver supports busy-polling, it tags each packet with
+ the receiving NAPI context, and kernel tags sockets
+ </li>
+ <li>
+ When busy-polling is enabled, <tt>poll()</tt>
+ and <tt>recv()</tt> call the driver's busy poll function to
+ check for packets synchronously (up to some time limit)
+ </li>
+ <li>
+ If the response usually arrives quickly, this reduces overall
+ request/response latency as there are no context switches and
+ power transitions
+ </li>
+ <li>
+ Time limit set by sysctl (<tt>net.busy_poll</tt>,
+ <tt>net.busy_read</tt>) or socket option (<tt>SOL_SOCKET,
+ SO_BUSY_POLL</tt>); requires tuning
+ </li>
+ </ul>
+</div>
+
<div class="slide">
<h1>Questions?</h1>
</div>