tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
doc: networking: prepare offload documents for conversion into RST
Add small number of markups which are sufficient for conversion
into reStructuredText.
Unfortunately there was necessary to restructure all sections
in checksum-offloads.txt file and create paragraphs separated
by newline. There also must not be a space at the
beginning of paragpraph.
There are no semantic changes.
Signed-off-by: Otto Sabart <ottosabart@seberm.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
authored by
Otto Sabart
and committed by
Jonathan Corbet
1b23f5e9
9f63df26
+129
-94
+99
-78
Documentation/networking/checksum-offloads.txt
+99
-78
Documentation/networking/checksum-offloads.txt
···
1
+
.. SPDX-License-Identifier: GPL-2.0
2
+
3
+
===============================================
1
4
Checksum Offloads in the Linux Networking Stack
5
+
===============================================
2
6
3
7
4
8
Introduction
5
9
============
6
10
7
-
This document describes a set of techniques in the Linux networking stack
8
-
to take advantage of checksum offload capabilities of various NICs.
11
+
This document describes a set of techniques in the Linux networking stack to
12
+
take advantage of checksum offload capabilities of various NICs.
9
13
10
14
The following technologies are described:
11
-
* TX Checksum Offload
12
-
* LCO: Local Checksum Offload
13
-
* RCO: Remote Checksum Offload
15
+
16
+
* TX Checksum Offload
17
+
* LCO: Local Checksum Offload
18
+
* RCO: Remote Checksum Offload
14
19
15
20
Things that should be documented here but aren't yet:
16
-
* RX Checksum Offload
17
-
* CHECKSUM_UNNECESSARY conversion
21
+
22
+
* RX Checksum Offload
23
+
* CHECKSUM_UNNECESSARY conversion
18
24
19
25
20
26
TX Checksum Offload
21
27
===================
22
28
23
-
The interface for offloading a transmit checksum to a device is explained
24
-
in detail in comments near the top of include/linux/skbuff.h.
29
+
The interface for offloading a transmit checksum to a device is explained in
30
+
detail in comments near the top of include/linux/skbuff.h.
31
+
25
32
In brief, it allows to request the device fill in a single ones-complement
26
-
checksum defined by the sk_buff fields skb->csum_start and
27
-
skb->csum_offset. The device should compute the 16-bit ones-complement
28
-
checksum (i.e. the 'IP-style' checksum) from csum_start to the end of the
29
-
packet, and fill in the result at (csum_start + csum_offset).
30
-
Because csum_offset cannot be negative, this ensures that the previous
31
-
value of the checksum field is included in the checksum computation, thus
32
-
it can be used to supply any needed corrections to the checksum (such as
33
-
the sum of the pseudo-header for UDP or TCP).
33
+
checksum defined by the sk_buff fields skb->csum_start and skb->csum_offset.
34
+
The device should compute the 16-bit ones-complement checksum (i.e. the
35
+
'IP-style' checksum) from csum_start to the end of the packet, and fill in the
36
+
result at (csum_start + csum_offset).
37
+
38
+
Because csum_offset cannot be negative, this ensures that the previous value of
39
+
the checksum field is included in the checksum computation, thus it can be used
40
+
to supply any needed corrections to the checksum (such as the sum of the
41
+
pseudo-header for UDP or TCP).
42
+
34
43
This interface only allows a single checksum to be offloaded. Where
35
-
encapsulation is used, the packet may have multiple checksum fields in
36
-
different header layers, and the rest will have to be handled by another
37
-
mechanism such as LCO or RCO.
44
+
encapsulation is used, the packet may have multiple checksum fields in
45
+
different header layers, and the rest will have to be handled by another
46
+
mechanism such as LCO or RCO.
47
+
38
48
CRC32c can also be offloaded using this interface, by means of filling
39
-
skb->csum_start and skb->csum_offset as described above, and setting
40
-
skb->csum_not_inet: see skbuff.h comment (section 'D') for more details.
49
+
skb->csum_start and skb->csum_offset as described above, and setting
50
+
skb->csum_not_inet: see skbuff.h comment (section 'D') for more details.
51
+
41
52
No offloading of the IP header checksum is performed; it is always done in
42
-
software. This is OK because when we build the IP header, we obviously
43
-
have it in cache, so summing it isn't expensive. It's also rather short.
53
+
software. This is OK because when we build the IP header, we obviously have it
54
+
in cache, so summing it isn't expensive. It's also rather short.
55
+
44
56
The requirements for GSO are more complicated, because when segmenting an
45
-
encapsulated packet both the inner and outer checksums may need to be
46
-
edited or recomputed for each resulting segment. See the skbuff.h comment
47
-
(section 'E') for more details.
57
+
encapsulated packet both the inner and outer checksums may need to be edited or
58
+
recomputed for each resulting segment. See the skbuff.h comment (section 'E')
59
+
for more details.
48
60
49
61
A driver declares its offload capabilities in netdev->hw_features; see
50
-
Documentation/networking/netdev-features.txt for more. Note that a device
51
-
which only advertises NETIF_F_IP[V6]_CSUM must still obey the csum_start
52
-
and csum_offset given in the SKB; if it tries to deduce these itself in
53
-
hardware (as some NICs do) the driver should check that the values in the
54
-
SKB match those which the hardware will deduce, and if not, fall back to
55
-
checksumming in software instead (with skb_csum_hwoffload_help() or one of
56
-
the skb_checksum_help() / skb_crc32c_csum_help functions, as mentioned in
57
-
include/linux/skbuff.h).
62
+
Documentation/networking/netdev-features.txt for more. Note that a device
63
+
which only advertises NETIF_F_IP[V6]_CSUM must still obey the csum_start and
64
+
csum_offset given in the SKB; if it tries to deduce these itself in hardware
65
+
(as some NICs do) the driver should check that the values in the SKB match
66
+
those which the hardware will deduce, and if not, fall back to checksumming in
67
+
software instead (with skb_csum_hwoffload_help() or one of the
68
+
skb_checksum_help() / skb_crc32c_csum_help functions, as mentioned in
69
+
include/linux/skbuff.h).
58
70
59
-
The stack should, for the most part, assume that checksum offload is
60
-
supported by the underlying device. The only place that should check is
61
-
validate_xmit_skb(), and the functions it calls directly or indirectly.
62
-
That function compares the offload features requested by the SKB (which
63
-
may include other offloads besides TX Checksum Offload) and, if they are
64
-
not supported or enabled on the device (determined by netdev->features),
65
-
performs the corresponding offload in software. In the case of TX
66
-
Checksum Offload, that means calling skb_csum_hwoffload_help(skb, features).
71
+
The stack should, for the most part, assume that checksum offload is supported
72
+
by the underlying device. The only place that should check is
73
+
validate_xmit_skb(), and the functions it calls directly or indirectly. That
74
+
function compares the offload features requested by the SKB (which may include
75
+
other offloads besides TX Checksum Offload) and, if they are not supported or
76
+
enabled on the device (determined by netdev->features), performs the
77
+
corresponding offload in software. In the case of TX Checksum Offload, that
78
+
means calling skb_csum_hwoffload_help(skb, features).
67
79
68
80
69
81
LCO: Local Checksum Offload
70
82
===========================
71
83
72
84
LCO is a technique for efficiently computing the outer checksum of an
73
-
encapsulated datagram when the inner checksum is due to be offloaded.
74
-
The ones-complement sum of a correctly checksummed TCP or UDP packet is
75
-
equal to the complement of the sum of the pseudo header, because everything
76
-
else gets 'cancelled out' by the checksum field. This is because the sum was
77
-
complemented before being written to the checksum field.
85
+
encapsulated datagram when the inner checksum is due to be offloaded.
86
+
87
+
The ones-complement sum of a correctly checksummed TCP or UDP packet is equal
88
+
to the complement of the sum of the pseudo header, because everything else gets
89
+
'cancelled out' by the checksum field. This is because the sum was
90
+
complemented before being written to the checksum field.
91
+
78
92
More generally, this holds in any case where the 'IP-style' ones complement
79
-
checksum is used, and thus any checksum that TX Checksum Offload supports.
93
+
checksum is used, and thus any checksum that TX Checksum Offload supports.
94
+
80
95
That is, if we have set up TX Checksum Offload with a start/offset pair, we
81
-
know that after the device has filled in that checksum, the ones
82
-
complement sum from csum_start to the end of the packet will be equal to
83
-
the complement of whatever value we put in the checksum field beforehand.
84
-
This allows us to compute the outer checksum without looking at the payload:
85
-
we simply stop summing when we get to csum_start, then add the complement of
86
-
the 16-bit word at (csum_start + csum_offset).
96
+
know that after the device has filled in that checksum, the ones complement sum
97
+
from csum_start to the end of the packet will be equal to the complement of
98
+
whatever value we put in the checksum field beforehand. This allows us to
99
+
compute the outer checksum without looking at the payload: we simply stop
100
+
summing when we get to csum_start, then add the complement of the 16-bit word
101
+
at (csum_start + csum_offset).
102
+
87
103
Then, when the true inner checksum is filled in (either by hardware or by
88
-
skb_checksum_help()), the outer checksum will become correct by virtue of
89
-
the arithmetic.
104
+
skb_checksum_help()), the outer checksum will become correct by virtue of the
105
+
arithmetic.
90
106
91
107
LCO is performed by the stack when constructing an outer UDP header for an
92
-
encapsulation such as VXLAN or GENEVE, in udp_set_csum(). Similarly for
93
-
the IPv6 equivalents, in udp6_set_csum().
108
+
encapsulation such as VXLAN or GENEVE, in udp_set_csum(). Similarly for the
109
+
IPv6 equivalents, in udp6_set_csum().
110
+
94
111
It is also performed when constructing an IPv4 GRE header, in
95
-
net/ipv4/ip_gre.c:build_header(). It is *not* currently performed when
96
-
constructing an IPv6 GRE header; the GRE checksum is computed over the
97
-
whole packet in net/ipv6/ip6_gre.c:ip6gre_xmit2(), but it should be
98
-
possible to use LCO here as IPv6 GRE still uses an IP-style checksum.
112
+
net/ipv4/ip_gre.c:build_header(). It is *not* currently performed when
113
+
constructing an IPv6 GRE header; the GRE checksum is computed over the whole
114
+
packet in net/ipv6/ip6_gre.c:ip6gre_xmit2(), but it should be possible to use
115
+
LCO here as IPv6 GRE still uses an IP-style checksum.
116
+
99
117
All of the LCO implementations use a helper function lco_csum(), in
100
-
include/linux/skbuff.h.
118
+
include/linux/skbuff.h.
101
119
102
120
LCO can safely be used for nested encapsulations; in this case, the outer
103
-
encapsulation layer will sum over both its own header and the 'middle'
104
-
header. This does mean that the 'middle' header will get summed multiple
105
-
times, but there doesn't seem to be a way to avoid that without incurring
106
-
bigger costs (e.g. in SKB bloat).
121
+
encapsulation layer will sum over both its own header and the 'middle' header.
122
+
This does mean that the 'middle' header will get summed multiple times, but
123
+
there doesn't seem to be a way to avoid that without incurring bigger costs
124
+
(e.g. in SKB bloat).
107
125
108
126
109
127
RCO: Remote Checksum Offload
110
128
============================
111
129
112
-
RCO is a technique for eliding the inner checksum of an encapsulated
113
-
datagram, allowing the outer checksum to be offloaded. It does, however,
114
-
involve a change to the encapsulation protocols, which the receiver must
115
-
also support. For this reason, it is disabled by default.
130
+
RCO is a technique for eliding the inner checksum of an encapsulated datagram,
131
+
allowing the outer checksum to be offloaded. It does, however, involve a
132
+
change to the encapsulation protocols, which the receiver must also support.
133
+
For this reason, it is disabled by default.
134
+
116
135
RCO is detailed in the following Internet-Drafts:
117
-
https://tools.ietf.org/html/draft-herbert-remotecsumoffload-00
118
-
https://tools.ietf.org/html/draft-herbert-vxlan-rco-00
119
-
In Linux, RCO is implemented individually in each encapsulation protocol,
120
-
and most tunnel types have flags controlling its use. For instance, VXLAN
121
-
has the flag VXLAN_F_REMCSUM_TX (per struct vxlan_rdst) to indicate that
122
-
RCO should be used when transmitting to a given remote destination.
136
+
137
+
* https://tools.ietf.org/html/draft-herbert-remotecsumoffload-00
138
+
* https://tools.ietf.org/html/draft-herbert-vxlan-rco-00
139
+
140
+
In Linux, RCO is implemented individually in each encapsulation protocol, and
141
+
most tunnel types have flags controlling its use. For instance, VXLAN has the
142
+
flag VXLAN_F_REMCSUM_TX (per struct vxlan_rdst) to indicate that RCO should be
143
+
used when transmitting to a given remote destination.
+30
-16
Documentation/networking/segmentation-offloads.txt
+30
-16
Documentation/networking/segmentation-offloads.txt
···
1
+
.. SPDX-License-Identifier: GPL-2.0
2
+
3
+
===================================================
1
4
Segmentation Offloads in the Linux Networking Stack
5
+
===================================================
6
+
2
7
3
8
Introduction
4
9
============
···
19
14
* Generic Receive Offload - GRO
20
15
* Partial Generic Segmentation Offload - GSO_PARTIAL
21
16
* SCTP accelleration with GSO - GSO_BY_FRAGS
17
+
22
18
23
19
TCP Segmentation Offload
24
20
========================
···
48
42
and we will either increment the IP ID for all frames, or leave it at a
49
43
static value based on driver preference.
50
44
45
+
51
46
UDP Fragmentation Offload
52
47
=========================
53
48
···
60
53
UFO is deprecated: modern kernels will no longer generate UFO skbs, but can
61
54
still receive them from tuntap and similar devices. Offload of UDP-based
62
55
tunnel protocols is still supported.
56
+
63
57
64
58
IPIP, SIT, GRE, UDP Tunnel, and Remote Checksum Offloads
65
59
========================================================
···
79
71
data is normally referred to as the inner headers. Below is the list of
80
72
calls to access the given headers:
81
73
82
-
IPIP/SIT Tunnel:
83
-
Outer Inner
84
-
MAC skb_mac_header
85
-
Network skb_network_header skb_inner_network_header
86
-
Transport skb_transport_header
74
+
IPIP/SIT Tunnel::
87
75
88
-
UDP/GRE Tunnel:
89
-
Outer Inner
90
-
MAC skb_mac_header skb_inner_mac_header
91
-
Network skb_network_header skb_inner_network_header
92
-
Transport skb_transport_header skb_inner_transport_header
76
+
Outer Inner
77
+
MAC skb_mac_header
78
+
Network skb_network_header skb_inner_network_header
79
+
Transport skb_transport_header
80
+
81
+
UDP/GRE Tunnel::
82
+
83
+
Outer Inner
84
+
MAC skb_mac_header skb_inner_mac_header
85
+
Network skb_network_header skb_inner_network_header
86
+
Transport skb_transport_header skb_inner_transport_header
93
87
94
88
In addition to the above tunnel types there are also SKB_GSO_GRE_CSUM and
95
89
SKB_GSO_UDP_TUNNEL_CSUM. These two additional tunnel types reflect the
···
102
92
header has requested a remote checksum offload. In this case the inner
103
93
headers will be left with a partial checksum and only the outer header
104
94
checksum will be computed.
95
+
105
96
106
97
Generic Segmentation Offload
107
98
============================
···
117
106
offload is required in GSO. Otherwise it becomes possible for a frame to
118
107
be re-routed between devices and end up being unable to be transmitted.
119
108
109
+
120
110
Generic Receive Offload
121
111
=======================
122
112
···
128
116
this is IPv4 ID in the case that the DF bit is set for a given IP header.
129
117
If the value of the IPv4 ID is not sequentially incrementing it will be
130
118
altered so that it is when a frame assembled via GRO is segmented via GSO.
119
+
131
120
132
121
Partial Generic Segmentation Offload
133
122
====================================
···
146
133
is the outer IPv4 ID field. It is up to the device drivers to guarantee
147
134
that the IPv4 ID field is incremented in the case that a given header does
148
135
not have the DF bit set.
136
+
149
137
150
138
SCTP accelleration with GSO
151
139
===========================
···
171
157
172
158
There are some helpers to make this easier:
173
159
174
-
- skb_is_gso(skb) && skb_is_gso_sctp(skb) is the best way to see if
175
-
an skb is an SCTP GSO skb.
160
+
- skb_is_gso(skb) && skb_is_gso_sctp(skb) is the best way to see if
161
+
an skb is an SCTP GSO skb.
176
162
177
-
- For size checks, the skb_gso_validate_*_len family of helpers correctly
178
-
considers GSO_BY_FRAGS.
163
+
- For size checks, the skb_gso_validate_*_len family of helpers correctly
164
+
considers GSO_BY_FRAGS.
179
165
180
-
- For manipulating packets, skb_increase_gso_size and skb_decrease_gso_size
181
-
will check for GSO_BY_FRAGS and WARN if asked to manipulate these skbs.
166
+
- For manipulating packets, skb_increase_gso_size and skb_decrease_gso_size
167
+
will check for GSO_BY_FRAGS and WARN if asked to manipulate these skbs.
182
168
183
169
This also affects drivers with the NETIF_F_FRAGLIST & NETIF_F_GSO_SCTP bits
184
170
set. Note also that NETIF_F_GSO_SCTP is included in NETIF_F_GSO_SOFTWARE.