summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2015-02-11 15:12:19 -0800
committerDavid S. Miller <davem@davemloft.net>2015-02-11 15:12:19 -0800
commit777b3e930ac8eb1f8360b3e4f2aaf5e4abe5ed46 (patch)
treefc3c9744cddeb0bba07c0ed258de06df4eb01487 /drivers/net/ethernet
parent13101602c4a9f653d59af9469040797bc5b361ca (diff)
parentfe881ef11cf0220f118816181930494d484c4883 (diff)
Merge branch 'rco_correctness'
Tom Herbert says: ==================== net: Fixes to remote checksum offload and CHECKSUM_PARTIAL This patch set fixes a correctness problem with remote checksum offload, clarifies the meaning of CHECKSUM_PARTIAL, and allows remote checksum offload to set CHECKSUM_PARTIAL instead of calling csum_partial and modifying the checksum. Specifically: - In the GRO remote checksum path, restore the checksum after calling lower layer GRO functions. This is needed if the packet is forwarded off host with the Remote Checksum Offload option still present. - Clarify meaning of CHECKSUM PARTIAL in the receive path. Only the checksums referred to by checksum partial and any preceding checksums can be considered verified. - Fixes to UDP tunnel GRO complete. Need to set SKB_GSO_UDP_TUNNEL_*, SKB_GSO_TUNNEL_REMCSUM, and skb->encapsulation for forwarding case. - Infrastructure to allow setting of CHECKSUM_PARTIAL in remote checksum offload. This a potential performance benefit instead of calling csum_partial (potentially twice, once in GRO path and once in normal path). The downside of using CHECKSUM_PARTIAL and not actually writing the checksum is that we aren't verifying that the sender correctly wrote the pseudo checksum into the checksum field, or that the start/offset values actually point to a checksum. If the sender did not set up these fields correctly, a packet might be accepted locally, but not accepted by a peer when the packet is forwarded off host. Verifying these fields seems non-trivial, and because the fields can only be incorrect due to sender error and not corruption (outer checksum protects against that) we'll make use of CHECKSUM_PARTIAL the default. This behavior can be reverted as an netlink option on the encapsulation socket. - Change VXLAN and GUE to set CHECKSUM_PARTIAL in remote checksum offload by default, configuration hooks can revert to using csum_partial. Testing: I ran performance numbers using netperf TCP_STREAM and TCP_RR with 200 streams for GRE/GUE and for VXLAN. This compares before the fixes, the fixes with not setting checksum partial in remote checksum offload, and with the fixes setting checksum partial. The overall effect seems be that using checksum partial is a slight performance win, perf definitely shows a significant reduction of time in csum_partial on the receive CPUs. GRE/GUE TCP_STREAM Before fixes 9.22% TX CPU utilization 13.57% RX CPU utilization 9133 Mbps Not using checksum partial 9.59% TX CPU utilization 14.95% RX CPU utilization 9132 Mbps Using checksum partial 9.37% TX CPU utilization 13.89% RX CPU utilization 9132 Mbps TCP_RR Before fixes CPU utilization 159/251/447 90/95/99% latencies 1.1462e+06 tps Not using checksum partial 92.94% CPU utilization 158/253/445 90/95/99% latencies 1.12988e+06 tps Using checksum partial 92.78% CPU utilization 158/250/450 90/95/99% latencies 1.15343e+06 tps VXLAN TCP_STREAM Before fixes 9.24% TX CPU utilization 13.74% RX CPU utilization 9093 Mbps Not using checksum partial 9.95% TX CPU utilization 14.66% RX CPU utilization 9094 Mbps Using checksum partial 10.24% TX CPU utilization 13.32% RX CPU utilization 9093 Mbps TCP_RR Before fixes 92.91% CPU utilization 151/241/437 90/95/99% latencies 1.15939e+06 tps Not using checksum partial 93.07% CPU utilization 156/246/425 90/95/99% latencies 1.1451e+06 tps Using checksum partial 95.51% CPU utilization 156/249/459 90/95/99% latencies 1.17004e+06 tps ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet')
0 files changed, 0 insertions, 0 deletions