[PATCH 0/3] Updates to segmentation-offloads.txt

[PATCH 0/3] Updates to segmentation-offloads.txt

[Daniel Axtens]

I've been trying to wrap my head around GSO for a while now. This is a
set of small changes to the docs that would probably have been helpful
when I was starting out.

I realise that GSO_DODGY is still a notable omission - I'm hesitant to
write too much on it just yet as I don't understand it well and I
think it's in the process of changing.

Daniel Axtens (3):
  docs: segmentation-offloads.txt: update for UFO depreciation
  docs: segmentation-offloads.txt: Fix ref to SKB_GSO_TUNNEL_REMCSUM
  docs: segmentation-offloads.txt: add SCTP info

 Documentation/networking/segmentation-offloads.txt | 38 +++++++++++++++++++---
 1 file changed, 34 insertions(+), 4 deletions(-)

-- 
2.14.1

[PATCH 1/3] docs: segmentation-offloads.txt: update for UFO depreciation

[Daniel Axtens]

UFO is deprecated except for tuntap and packet per 0c19f846d582,
("net: accept UFO datagrams from tuntap and packet"). Update UFO
docs to reflect this.

Signed-off-by: Daniel Axtens <dja@axtens.net>
---
 Documentation/networking/segmentation-offloads.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/networking/segmentation-offloads.txt b/Documentation/networking/segmentation-offloads.txt
index 2f09455a993a..2cda12ab7075 100644
--- a/Documentation/networking/segmentation-offloads.txt
+++ b/Documentation/networking/segmentation-offloads.txt
@@ -49,6 +49,10 @@ datagram into multiple IPv4 fragments.  Many of the requirements for UDP
 fragmentation offload are the same as TSO.  However the IPv4 ID for
 fragments should not increment as a single IPv4 datagram is fragmented.
 
+UFO is deprecated: modern kernels will no longer generate UFO skbs, but can
+still receive them from tuntap and similar devices. Offload of UDP-based
+tunnel protocols is still supported.
+
 IPIP, SIT, GRE, UDP Tunnel, and Remote Checksum Offloads
 ========================================================
 
-- 
2.14.1

[PATCH 2/3] docs: segmentation-offloads.txt: Fix ref to SKB_GSO_TUNNEL_REMCSUM

[Daniel Axtens]

The doc originally called it SKB_GSO_REMCSUM. Fix it.

Fixes: f7a6272bf3cb ("Documentation: Add documentation for TSO and GSO features")
Signed-off-by: Daniel Axtens <dja@axtens.net>
--
The only text change is s/SKB_GSO_REMCSUM/SKB_GSO_TUNNEL_REMCSUM/, but
I rewrapped the text which is why the whole para changed.

---
 Documentation/networking/segmentation-offloads.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/networking/segmentation-offloads.txt b/Documentation/networking/segmentation-offloads.txt
index 2cda12ab7075..b247471a183c 100644
--- a/Documentation/networking/segmentation-offloads.txt
+++ b/Documentation/networking/segmentation-offloads.txt
@@ -87,10 +87,10 @@ SKB_GSO_UDP_TUNNEL_CSUM.  These two additional tunnel types reflect the
 fact that the outer header also requests to have a non-zero checksum
 included in the outer header.
 
-Finally there is SKB_GSO_REMCSUM which indicates that a given tunnel header
-has requested a remote checksum offload.  In this case the inner headers
-will be left with a partial checksum and only the outer header checksum
-will be computed.
+Finally there is SKB_GSO_TUNNEL_REMCSUM which indicates that a given tunnel
+header has requested a remote checksum offload.  In this case the inner
+headers will be left with a partial checksum and only the outer header
+checksum will be computed.
 
 Generic Segmentation Offload
 ============================
-- 
2.14.1

[PATCH 3/3] docs: segmentation-offloads.txt: add SCTP info

[Daniel Axtens]

Most of this is extracted from 90017accff61 ("sctp: Add GSO support"),
with some extra text about GSO_BY_FRAGS and the need to check for it.

Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
---
 Documentation/networking/segmentation-offloads.txt | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/networking/segmentation-offloads.txt b/Documentation/networking/segmentation-offloads.txt
index b247471a183c..d47480b61ac6 100644
--- a/Documentation/networking/segmentation-offloads.txt
+++ b/Documentation/networking/segmentation-offloads.txt
@@ -13,6 +13,7 @@ The following technologies are described:
  * Generic Segmentation Offload - GSO
  * Generic Receive Offload - GRO
  * Partial Generic Segmentation Offload - GSO_PARTIAL
+ * SCTP accelleration with GSO - GSO_BY_FRAGS
 
 TCP Segmentation Offload
 ========================
@@ -132,3 +133,28 @@ values for if the header was simply duplicated.  The one exception to this
 is the outer IPv4 ID field.  It is up to the device drivers to guarantee
 that the IPv4 ID field is incremented in the case that a given header does
 not have the DF bit set.
+
+SCTP accelleration with GSO
+===========================
+
+SCTP - despite the lack of hardware support - can still take advantage of
+GSO to pass one large packet through the network stack, rather than
+multiple small packets.
+
+This requires a different approach to other offloads, as SCTP packets
+cannot be just segmented to (P)MTU. Rather, the chunks must be contained in
+IP segments, padding respected. So unlike regular GSO, SCTP can't just
+generate a big skb, set gso_size to the fragmentation point and deliver it
+to IP layer.
+
+Instead, the SCTP protocol layer builds an skb with the segments correctly
+padded and stored as chained skbs, and skb_segment() splits based on those.
+To signal this, gso_size is set to the special value GSO_BY_FRAGS.
+
+Therefore, any code in the core networking stack must be aware of the
+possibility that gso_size will be GSO_BY_FRAGS and handle that case
+appropriately. (For size checks, the skb_gso_validate_*_len family of
+helpers do this automatically.)
+
+This also affects drivers with the NETIF_F_FRAGLIST & NETIF_F_GSO_SCTP bits
+set. Note also that NETIF_F_GSO_SCTP is included in NETIF_F_GSO_SOFTWARE.
-- 
2.14.1

Re: [PATCH 3/3] docs: segmentation-offloads.txt: add SCTP info

[Marcelo Ricardo Leitner]

On Wed, Feb 14, 2018 at 06:05:33PM +1100, Daniel Axtens wrote:
> Most of this is extracted from 90017accff61 ("sctp: Add GSO support"),
> with some extra text about GSO_BY_FRAGS and the need to check for it.
> 
> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Daniel Axtens <dja@axtens.net>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  Documentation/networking/segmentation-offloads.txt | 26 ++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/Documentation/networking/segmentation-offloads.txt b/Documentation/networking/segmentation-offloads.txt
> index b247471a183c..d47480b61ac6 100644
> --- a/Documentation/networking/segmentation-offloads.txt
> +++ b/Documentation/networking/segmentation-offloads.txt
> @@ -13,6 +13,7 @@ The following technologies are described:
>   * Generic Segmentation Offload - GSO
>   * Generic Receive Offload - GRO
>   * Partial Generic Segmentation Offload - GSO_PARTIAL
> + * SCTP accelleration with GSO - GSO_BY_FRAGS
>  
>  TCP Segmentation Offload
>  ========================
> @@ -132,3 +133,28 @@ values for if the header was simply duplicated.  The one exception to this
>  is the outer IPv4 ID field.  It is up to the device drivers to guarantee
>  that the IPv4 ID field is incremented in the case that a given header does
>  not have the DF bit set.
> +
> +SCTP accelleration with GSO
> +===========================
> +
> +SCTP - despite the lack of hardware support - can still take advantage of
> +GSO to pass one large packet through the network stack, rather than
> +multiple small packets.
> +
> +This requires a different approach to other offloads, as SCTP packets
> +cannot be just segmented to (P)MTU. Rather, the chunks must be contained in
> +IP segments, padding respected. So unlike regular GSO, SCTP can't just
> +generate a big skb, set gso_size to the fragmentation point and deliver it
> +to IP layer.
> +
> +Instead, the SCTP protocol layer builds an skb with the segments correctly
> +padded and stored as chained skbs, and skb_segment() splits based on those.
> +To signal this, gso_size is set to the special value GSO_BY_FRAGS.
> +
> +Therefore, any code in the core networking stack must be aware of the
> +possibility that gso_size will be GSO_BY_FRAGS and handle that case
> +appropriately. (For size checks, the skb_gso_validate_*_len family of
> +helpers do this automatically.)
> +
> +This also affects drivers with the NETIF_F_FRAGLIST & NETIF_F_GSO_SCTP bits
> +set. Note also that NETIF_F_GSO_SCTP is included in NETIF_F_GSO_SOFTWARE.
> -- 
> 2.14.1
> 

Re: [PATCH 3/3] docs: segmentation-offloads.txt: add SCTP info

[Marcelo Ricardo Leitner]

On Wed, Feb 14, 2018 at 06:05:33PM +1100, Daniel Axtens wrote:
> Most of this is extracted from 90017accff61 ("sctp: Add GSO support"),
> with some extra text about GSO_BY_FRAGS and the need to check for it.
> 
> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Daniel Axtens <dja@axtens.net>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  Documentation/networking/segmentation-offloads.txt | 26 ++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/Documentation/networking/segmentation-offloads.txt b/Documentation/networking/segmentation-offloads.txt
> index b247471a183c..d47480b61ac6 100644
> --- a/Documentation/networking/segmentation-offloads.txt
> +++ b/Documentation/networking/segmentation-offloads.txt
> @@ -13,6 +13,7 @@ The following technologies are described:
>   * Generic Segmentation Offload - GSO
>   * Generic Receive Offload - GRO
>   * Partial Generic Segmentation Offload - GSO_PARTIAL
> + * SCTP accelleration with GSO - GSO_BY_FRAGS
>  
>  TCP Segmentation Offload
>  ============
> @@ -132,3 +133,28 @@ values for if the header was simply duplicated.  The one exception to this
>  is the outer IPv4 ID field.  It is up to the device drivers to guarantee
>  that the IPv4 ID field is incremented in the case that a given header does
>  not have the DF bit set.
> +
> +SCTP accelleration with GSO
> +=============> +
> +SCTP - despite the lack of hardware support - can still take advantage of
> +GSO to pass one large packet through the network stack, rather than
> +multiple small packets.
> +
> +This requires a different approach to other offloads, as SCTP packets
> +cannot be just segmented to (P)MTU. Rather, the chunks must be contained in
> +IP segments, padding respected. So unlike regular GSO, SCTP can't just
> +generate a big skb, set gso_size to the fragmentation point and deliver it
> +to IP layer.
> +
> +Instead, the SCTP protocol layer builds an skb with the segments correctly
> +padded and stored as chained skbs, and skb_segment() splits based on those.
> +To signal this, gso_size is set to the special value GSO_BY_FRAGS.
> +
> +Therefore, any code in the core networking stack must be aware of the
> +possibility that gso_size will be GSO_BY_FRAGS and handle that case
> +appropriately. (For size checks, the skb_gso_validate_*_len family of
> +helpers do this automatically.)
> +
> +This also affects drivers with the NETIF_F_FRAGLIST & NETIF_F_GSO_SCTP bits
> +set. Note also that NETIF_F_GSO_SCTP is included in NETIF_F_GSO_SOFTWARE.
> -- 
> 2.14.1
> 

Re: [PATCH 0/3] Updates to segmentation-offloads.txt

[David Miller]

From: Daniel Axtens <dja@axtens.net>
Date: Wed, 14 Feb 2018 18:05:30 +1100

> I've been trying to wrap my head around GSO for a while now. This is a
> set of small changes to the docs that would probably have been helpful
> when I was starting out.
> 
> I realise that GSO_DODGY is still a notable omission - I'm hesitant to
> write too much on it just yet as I don't understand it well and I
> think it's in the process of changing.

Series applied, thanks for doing this.

Generally speaking, the "dodgy" attributes mean that the packet came from
an "untrusted" source such as a virtualization guest or similar.

When set, it tells us that we cannot trust the GSO attributes of the
packet nor the geometry of the SKB.  For example, a malicious guest
could sent us a TCP packet, yet set SCTP GSO attributes.

It largely means that we have to perform extra verifications and sanity
checking that would not be necessary for in-kernel generated GSO packets
which we could assume are properly formed.

Thanks.