X-Git-Url: https://git.decadent.org.uk/gitweb/?p=kernel-news-talk.git;a=blobdiff_plain;f=index.html;h=e899889c3d6e4115aedad2e6ec9aa69118e00cf9;hp=30405ac15bc94b29f69eb5dd85db795be0f8d7ad;hb=a9799692a7332a902e973c83dbad32c7e2917f4d;hpb=99ea3b2f5f0eb8fe7820296f3c44d5fcd335cd1d
diff --git a/index.html b/index.html
index 30405ac..e899889 100644
--- a/index.html
+++ b/index.html
@@ -191,6 +191,68 @@
+
+
Network busy-polling [3.11] (1)
+
A conventional network request/response process looks like:
+
+
+ -
+ Task calls send(); network stack constructs a
+ packet; driver adds it to hardware Tx queue
+
+ -
+ Task calls poll() or recv(), which blocks;
+ kernel puts it to sleep and possibly idles the CPU
+
+ -
+ Network adapter receives response and generates IRQ, waking
+ up CPU
+
+ -
+ Driver's IRQ handler schedules polling of the hardware Rx
+ queue (NAPI)
+
+ -
+ Kernel runs the driver's NAPI poll function, which passes
+ the response packet into the network stack
+
+ -
+ Network stack decodes packet headers and adds packet to
+ the task's socket
+
+ -
+ Network stack wakes up sleeping task; scheduler switches
+ to it and the socket call returns
+
+
+
+
+
+
+
Network busy-polling [3.11] (2)
+
+ -
+ If driver supports busy-polling, it tags each packet with
+ the receiving NAPI context, and kernel tags sockets
+
+ -
+ When busy-polling is enabled, poll()
+ and recv() call the driver's busy poll function to
+ check for packets synchronously (up to some time limit)
+
+ -
+ If the response usually arrives quickly, this reduces overall
+ request/response latency as there are no context switches and
+ power transitions
+
+ -
+ Time limit set by sysctl (net.busy_poll,
+ net.busy_read) or socket option (SOL_SOCKET,
+ SO_BUSY_POLL); requires tuning
+
+
+
+
Questions?