+25
−13
+52
−10
+26
−6
+5
−0
+3
−1
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
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>
CRA Git | Maintained and supported by SUSTech CRA and CCSE