summaryrefslogtreecommitdiff
path: root/2005/flow-accounting-ols2005/OLS2005/grossman/grossman-abstract.tex
diff options
context:
space:
mode:
Diffstat (limited to '2005/flow-accounting-ols2005/OLS2005/grossman/grossman-abstract.tex')
-rw-r--r--2005/flow-accounting-ols2005/OLS2005/grossman/grossman-abstract.tex31
1 files changed, 31 insertions, 0 deletions
diff --git a/2005/flow-accounting-ols2005/OLS2005/grossman/grossman-abstract.tex b/2005/flow-accounting-ols2005/OLS2005/grossman/grossman-abstract.tex
new file mode 100644
index 0000000..dbbeb54
--- /dev/null
+++ b/2005/flow-accounting-ols2005/OLS2005/grossman/grossman-abstract.tex
@@ -0,0 +1,31 @@
+
+% Registration Large Receive Offload implementation in
+% Neterion 10GbE Ethernet driver
+% Leonid Grossman (leonid@neterion.com)
+
+The benefits of Transmit Side Offload (TSO)
+implementation in Ethernet ASICs and device
+drivers are well known. TSO is a \textit{de facto}
+standard in 2.6 Linux kernel and provides
+significant reduction in \%cpu utilization,
+especially with 1500 MTU. On a cpu-bound
+system, these cycles translate into dramatic
+throughput increase. Unlike TOE, stateless
+offloads do not break the Linux stack and do
+not introduce security and support issues.
+Stateless offload benefits are especially
+apparent at 10 Gigabit rates. 10GbE sender
+with TSO hardware support uses a fraction of a
+single cpu to run at line rate, leaving plenty
+of cycles for applications. On the receiver
+side, the Linux stack presently does not have
+a stateless offload similar to TSO. Receiver
+\%cpu typically becomes a bottleneck that
+prevents 10GbE adapters from reaching line
+rate with 1500 mtu. Neterion hw/sw Large
+Receive Offload (LRO) solution was designed to
+address this bottleneck and further reduce TCP
+processing overhead on the receiver. Both
+design and performance results will be
+presented.
+
personal git repositories of Harald Welte. Your mileage may vary