udp gso

From: Willem de Bruijn <[email protected]>

Virtual devices such as tunnels and bonding can handle large packets. Only segment packets when reaching a physical or loopback device.

Signed-off-by Willem de Bruijn <[email protected]>

---
 include/linux/netdev_features.h | 3 +++
 1 file changed, 3 insertions(+)

include/linux/netdev_features.h +0 -0

index 35b79f47a13d..1e4883bb02a7 100644

include/linux/netdev_features.h +2 -1

        /*
         * Add your fresh new feature above and remember to update

@@ -147,6 +148,7 @@ enum {
 #define NETIF_F_HW_ESP_TX_CSUM __NETIF_F(HW_ESP_TX_CSUM)
 #define        NETIF_F_RX_UDP_TUNNEL_PORT  __NETIF_F(RX_UDP_TUNNEL_PORT)
 #define NETIF_F_HW_TLS_RECORD  __NETIF_F(HW_TLS_RECORD)
+#define NETIF_F_GSO_UDP_L4     __NETIF_F(GSO_UDP_L4)
 
 #define for_each_netdev_feature(mask_addr, bit)        \
        for_each_set_bit(bit, (unsigned long *)mask_addr, NETDEV_FEATURE_COUNT)

@@ -216,6 +218,7 @@ enum {
                                 NETIF_F_GSO_GRE_CSUM |                 \
                                 NETIF_F_GSO_IPXIP4 |                   \
                                 NETIF_F_GSO_IPXIP6 |                   \
+                                NETIF_F_GSO_UDP_L4 |                   \
                                 NETIF_F_GSO_UDP_TUNNEL |               \
                                 NETIF_F_GSO_UDP_TUNNEL_CSUM)
 
--

2.17.0.484.g0c8726318c-goog

Quoted 16 lines · Willem de Bruijn

From: Willem de Bruijn <[email protected]>

Virtual devices such as tunnels and bonding can handle large packets. Only segment packets when reaching a physical or loopback device.

Signed-off-by Willem de Bruijn <[email protected]>

---
 include/linux/netdev_features.h | 3 +++
 1 file changed, 3 insertions(+)

include/linux/netdev_features.h +0 -0

index 35b79f47a13d..1e4883bb02a7 100644
@@ -80,6 +80,7 @@ enum {
 

include/linux/netdev_features.h enum { · line 83

Quoted 3 lines

include/linux/netdev_features.h +1 -0

        NETIF_F_GRO_HW_BIT,             /* Hardware Generic receive offload */
        NETIF_F_HW_TLS_RECORD_BIT,      /* Offload TLS record */
+       NETIF_F_GSO_UDP_L4_BIT,         /* UDP payload GSO (not UFO) */

Please add an entry for the new flag to net/core/ethtool.c:netdev_features_strings
and a description to Documentation/networking/netdev-features.txt.

This patchset implements GSO for UDP. A process can concatenate and submit multiple datagrams to the same destination in one send call by setting socket option SOL_UDP/UDP_SEGMENT with the segment size, or passing an analogous cmsg at send time.

The stack will send the entire large (up to network layer max size) datagram through the protocol layer. At the GSO layer, it is broken up in individual segments. All receive the same network layer header and UDP src and dst port. All but the last segment have the same UDP header, but the last may differ in length and checksum.

Quoted 6 lines · Willem de Bruijn

This patchset implements GSO for UDP. A process can concatenate and submit multiple datagrams to the same destination in one send call by setting socket option SOL_UDP/UDP_SEGMENT with the segment size, or passing an analogous cmsg at send time.

Quoted 5 lines

The stack will send the entire large (up to network layer max size) datagram through the protocol layer. At the GSO layer, it is broken up in individual segments. All receive the same network layer header and UDP src and dst port. All but the last segment have the same UDP header, but the last may differ in length and checksum.

I'll go through the patch-set later today/tomorrow (interesting!),

but a question: what are message boundary semantics in this model? E.g., if I do a udp_sendmsg of 2000 bytes, and then then a udp_sendmsg of 512 bytes, with the receiver first recvmsg 2000 bytes and then the 512 bytes?

My understanding of the comment above is that no, it will not- because (assuming an mtu of 1500) there will be 2 UDP messages on the wire, the first one with 1500 bytes, and the second with 1012 bytes (with some discounts for the various L2/L3 etc headers)

Assuming IPv4 with an MTU of 1500 and the maximum segment size of 1472, the receiver will see three datagrams with MSS of 1472B, 528B and 512B.

Quoted 4 lines · Willem de Bruijn

Assuming IPv4 with an MTU of 1500 and the maximum segment size of 1472, the receiver will see three datagrams with MSS of 1472B, 528B and 512B.

so the recvmsg will also pass up 1472, 526, 512, right?

If yes, how will the recvmsg differentiate between the case (2000 byte message followed by 512 byte message) and (1472 byte message, 526 byte message, then 512 byte message), in other words, how are UDP message boundary semantics preserved?

Quoted 5 lines · Sowmini Varadhan

Quoted 3 lines · Willem de Bruijn

Assuming IPv4 with an MTU of 1500 and the maximum segment size of 1472, the receiver will see three datagrams with MSS of 1472B, 528B and 512B.

so the recvmsg will also pass up 1472, 526, 512, right?

That's right.

Quoted 4 lines

If yes, how will the recvmsg differentiate between the case (2000 byte message followed by 512 byte message) and (1472 byte message, 526 byte message, then 512 byte message), in other words, how are UDP message boundary semantics preserved?

They aren't. This is purely an optimization to amortize the cost of repeated tx stack traversal. Unlike UFO, which would preserve the boundaries of the original larger than MTU datagram.

A prime use case is bulk transfer of data. Think video streaming with QUIC. It must send MTU sized or smaller packets, but has no application-layer requirement to reconstruct large packets on the peer.

That said, for negotiated flows an inverse GRO feature could conceivably be implemented to reduce rx stack traversal, too. Though due to interleaving of packets on the wire, it aggregation would be best effort, similar to TCP TSO and GRO using the PSH bit as packetization signal.

Quoted 19 lines · Willem de Bruijn

Quoted 8 lines · Sowmini Varadhan

Quoted 4 lines · Willem de Bruijn

Assuming IPv4 with an MTU of 1500 and the maximum segment size of 1472, the receiver will see three datagrams with MSS of 1472B, 528B and 512B.

so the recvmsg will also pass up 1472, 526, 512, right?

That's right.

Quoted 4 lines

If yes, how will the recvmsg differentiate between the case (2000 byte message followed by 512 byte message) and (1472 byte message, 526 byte message, then 512 byte message), in other words, how are UDP message boundary semantics preserved?

Quoted 3 lines

They aren't. This is purely an optimization to amortize the cost of repeated tx stack traversal. Unlike UFO, which would preserve the boundaries of the original larger than MTU datagram.

Doesn't this break UDP applications that expect message boundary preservation semantics? Is it possible to negotiate this feature?

Quoted 10 lines

A prime use case is bulk transfer of data. Think video streaming with QUIC. It must send MTU sized or smaller packets, but has no application-layer requirement to reconstruct large packets on the peer.

That said, for negotiated flows an inverse GRO feature could conceivably be implemented to reduce rx stack traversal, too. Though due to interleaving of packets on the wire, it aggregation would be best effort, similar to TCP TSO and GRO using the PSH bit as packetization signal.

I went through the patch set and the code looks fine- it extends existing infra for TCP/GSO to UDP.

One thing that was not clear to me about the API: shouldn't UDP_SEGMENT just be automatically determined in the stack from the pmtu? Whats the motivation for the socket option for this? also AIUI this can be either a per-socket or a per-packet option?

However, I share Sridhar's concerns about the very fundamental change to UDP message boundary semantics here.

There is no change at all.

This will only be used as a mechanism to send X packets of same size.

So instead of X system calls , one system call.

One traversal of some expensive part of the host stack.

The content on the wire should be the same.

Quoted 10 lines · Eric Dumazet

There is no change at all.

This will only be used as a mechanism to send X packets of same size.

So instead of X system calls , one system call.

One traversal of some expensive part of the host stack.

The content on the wire should be the same.

I'm sorry that's not how I interpret Willem's email below (and maybe I misunderstood)

the following taken from https://www.spinics.net/lists/netdev/msg496150.html

Sowmini> If yes, how will the recvmsg differentiate between the case Sowmini> (2000 byte message followed by 512 byte message) and Sowmini> (1472 byte message, 526 byte message, then 512 byte message), Sowmini> in other words, how are UDP message boundary semantics preserved?

Willem> They aren't. This is purely an optimization to amortize the cost of Willem> repeated tx stack traversal. Unlike UFO, which would preserve the Willem> boundaries of the original larger than MTU datagram.

As I understand Willem's explanation, if I do a sendmsg of 2000 bytes,
- classic UDP will send 2 IP fragments, the first one with a full UDP header, and the IP header indicating that this is the first frag for that ipid, with more frags to follow. The second frag will have the rest with the same ipid, it will not have a udp header, and it will indicatet that it is the last frag (no more frags).

The receiver can thus use the ipid, "more-frags" bit, frag offset etc to stitch the 2000 byte udp message together and pass it up on the udp socket.

- in the "GSO" proposal my 2000 bytes of data are sent as *two* udp packets, each of them with a unique udp header, and uh_len set to 1476 (for first) and 526 (for second). The receiver has no clue that they are both part of the same UDP datagram, So wire format is not the same, am I mistaken?

Quoted 35 lines · Sowmini Varadhan

Quoted 9 lines · Eric Dumazet

There is no change at all.

This will only be used as a mechanism to send X packets of same size.

So instead of X system calls , one system call.

One traversal of some expensive part of the host stack.

The content on the wire should be the same.

I'm sorry that's not how I interpret Willem's email below (and maybe I misunderstood)

the following taken from https://www.spinics.net/lists/netdev/msg496150.html

Sowmini> If yes, how will the recvmsg differentiate between the case Sowmini> (2000 byte message followed by 512 byte message) and Sowmini> (1472 byte message, 526 byte message, then 512 byte message), Sowmini> in other words, how are UDP message boundary semantics preserved?

Willem> They aren't. This is purely an optimization to amortize the cost of Willem> repeated tx stack traversal. Unlike UFO, which would preserve the Willem> boundaries of the original larger than MTU datagram.

As I understand Willem's explanation, if I do a sendmsg of 2000 bytes,
- classic UDP will send 2 IP fragments, the first one with a full UDP header, and the IP header indicating that this is the first frag for that ipid, with more frags to follow. The second frag will have the rest with the same ipid, it will not have a udp header, and it will indicatet that it is the last frag (no more frags).

The receiver can thus use the ipid, "more-frags" bit, frag offset etc to stitch the 2000 byte udp message together and pass it up on the udp socket.

Quoted 5 lines

- in the "GSO" proposal my 2000 bytes of data are sent as *two* udp packets, each of them with a unique udp header, and uh_len set to 1476 (for first) and 526 (for second). The receiver has no clue that they are both part of the same UDP datagram, So wire format is not the same, am I mistaken?

Eric is correct. If the application sets a segment size with UDP_SEGMENT this is an instruction to the kernel to split the payload along that border into separate discrete datagrams.

It does not matter what the behavior is without setting this option. If a process wants to send a larger than MTU datagram and rely on the kernel to fragment, then it should not set the option.

Eric is correct. If the application sets a segment size with UDP_SEGMENT this is an instruction to the kernel to split the payload along that border into separate discrete datagrams.

It does not matter what the behavior is without setting this option. If a process wants to send a larger than MTU datagram and rely on the kernel to fragment, then it should not set the option.

- in the "GSO" proposal my 2000 bytes of data are sent as *two* udp packets, each of them with a unique udp header, and uh_len set to 1476 (for first) and 526 (for second). The receiver has no clue that they are both part of the same UDP datagram, So wire format is not the same, am I mistaken?

One thing that was not clear to me about the API: shouldn't UDP_SEGMENT just be automatically determined in the stack from the pmtu? Whats the motivation for the socket option for this? also AIUI this can be either a per-socket or a per-packet option?

Quoted 4 lines

One thing that was not clear to me about the API: shouldn't UDP_SEGMENT just be automatically determined in the stack from the pmtu? Whats the motivation for the socket option for this? also AIUI this can be either a per-socket or a per-packet option?

However, I share Sridhar's concerns about the very fundamental change to UDP message boundary semantics here. There is actually no such thing as a "segment" in udp, so in general this feature makes me a little uneasy. Well behaved udp applications should already be sending mtu sized datagrams. And the not-so-well-behaved ones are probably relying on IP fragmentation/reassembly to take care of datagram boundary semantics for them?

As Sridhar points out, the feature is not really "negotiated" - one side unilaterally sets the option. If the receiver is a classic/POSIX UDP implementation, it will have no way of knowing that message boundaries have been re-adjusted at the sender.

From: Sowmini Varadhan <[email protected]>
Date: Wed, 18 Apr 2018 08:31:03 -0400

Quoted 8 lines

However, I share Sridhar's concerns about the very fundamental change to UDP message boundary semantics here. There is actually no such thing as a "segment" in udp, so in general this feature makes me a little uneasy. Well behaved udp applications should already be sending mtu sized datagrams. And the not-so-well-behaved ones are probably relying on IP fragmentation/reassembly to take care of datagram boundary semantics for them?

Quoted 4 lines

As Sridhar points out, the feature is not really "negotiated" - one side unilaterally sets the option. If the receiver is a classic/POSIX UDP implementation, it will have no way of knowing that message boundaries have been re-adjusted at the sender.

There are no "semantics".

What ends up on the wire is the same before the kernel/app changes as afterwards.

The only difference is that instead of the application doing N - 1 sendmsg() calls with mtu sized writes, it's giving everything all at once and asking the kernel to segment.

It even gives the application control over the size of the packets, which I think is completely prudent in this situation.

Quoted 25 lines · David Miller

From: Sowmini Varadhan <[email protected]>
Date: Wed, 18 Apr 2018 08:31:03 -0400

Quoted 8 lines

However, I share Sridhar's concerns about the very fundamental change to UDP message boundary semantics here. There is actually no such thing as a "segment" in udp, so in general this feature makes me a little uneasy. Well behaved udp applications should already be sending mtu sized datagrams. And the not-so-well-behaved ones are probably relying on IP fragmentation/reassembly to take care of datagram boundary semantics for them?

Quoted 4 lines

As Sridhar points out, the feature is not really "negotiated" - one side unilaterally sets the option. If the receiver is a classic/POSIX UDP implementation, it will have no way of knowing that message boundaries have been re-adjusted at the sender.

There are no "semantics".

What ends up on the wire is the same before the kernel/app changes as afterwards.

The only difference is that instead of the application doing N - 1 sendmsg() calls with mtu sized writes, it's giving everything all at once and asking the kernel to segment.

Quoted 2 lines

It even gives the application control over the size of the packets, which I think is completely prudent in this situation.

My only concern with the patch set is verifying what mitigations are in case so that we aren't trying to set an MSS size that results in a frame larger than MTU. I'm still digging through the code and trying to grok it, but I figured I might just put the question out there to may my reviewing easier.

Also any plans for HW offload support for this? I vaguely recall that the igb and ixgbe parts had support for something like this in hardware. I would have to double check to see what exactly is supported.

Quoted 26 lines · Alexander Duyck

Quoted 25 lines · David Miller

From: Sowmini Varadhan <[email protected]>
Date: Wed, 18 Apr 2018 08:31:03 -0400

Quoted 8 lines

However, I share Sridhar's concerns about the very fundamental change to UDP message boundary semantics here. There is actually no such thing as a "segment" in udp, so in general this feature makes me a little uneasy. Well behaved udp applications should already be sending mtu sized datagrams. And the not-so-well-behaved ones are probably relying on IP fragmentation/reassembly to take care of datagram boundary semantics for them?

Quoted 4 lines

As Sridhar points out, the feature is not really "negotiated" - one side unilaterally sets the option. If the receiver is a classic/POSIX UDP implementation, it will have no way of knowing that message boundaries have been re-adjusted at the sender.

There are no "semantics".

What ends up on the wire is the same before the kernel/app changes as afterwards.

The only difference is that instead of the application doing N - 1 sendmsg() calls with mtu sized writes, it's giving everything all at once and asking the kernel to segment.

Quoted 8 lines

Quoted 2 lines

It even gives the application control over the size of the packets, which I think is completely prudent in this situation.

My only concern with the patch set is verifying what mitigations are in case so that we aren't trying to set an MSS size that results in a frame larger than MTU. I'm still digging through the code and trying to grok it, but I figured I might just put the question out there to may my reviewing easier.

This is checked in udp_send_skb in

                const int hlen = skb_network_header_len(skb) +
                                 sizeof(struct udphdr);

                if (hlen + cork->gso_size > cork->fragsize)
                        return -EINVAL;

At this point cork->fragsize will have been set in ip_setup_cork based on device or path mtu:

        cork->fragsize = ip_sk_use_pmtu(sk) ?
                         dst_mtu(&rt->dst) : rt->dst.dev->mtu;

The feature bypasses the MTU sanity checks in __ip_append_data by setting local variable mtu to a network layer max

        mtu = cork->gso_size ? IP_MAX_MTU : cork->fragsize;

but the above should perform the same check, only later. The check in udp_send_skb is simpler as it does not have to deal with the case of fragmentation.

Quoted 4 lines

Also any plans for HW offload support for this? I vaguely recall that the igb and ixgbe parts had support for something like this in hardware. I would have to double check to see what exactly is supported.

I hadn't given that much thought until the request yesterday to expose the NETIF_F_GSO_UDP_L4 flag through ethtool. By virtue of having only a single fixed segmentation length, it appears reasonably straightforward to offload.

Quoted 9 lines

Quoted 4 lines

Also any plans for HW offload support for this? I vaguely recall that the igb and ixgbe parts had support for something like this in hardware. I would have to double check to see what exactly is supported.

I hadn't given that much thought until the request yesterday to expose the NETIF_F_GSO_UDP_L4 flag through ethtool. By virtue of having only a single fixed segmentation length, it appears reasonably straightforward to offload.

Actually I just got a chance to start on a review of things. Do we need to have to use both GSO_UDP and and GSO_UDP_L4? It might be better if we could split these up and specifically call out GSO_UDP as UFO and GSO_UDP_L4 as being UDP segmentation.

Quoted 10 lines

Quoted 9 lines

Quoted 4 lines

Also any plans for HW offload support for this? I vaguely recall that the igb and ixgbe parts had support for something like this in hardware. I would have to double check to see what exactly is supported.

I hadn't given that much thought until the request yesterday to expose the NETIF_F_GSO_UDP_L4 flag through ethtool. By virtue of having only a single fixed segmentation length, it appears reasonably straightforward to offload.

Quoted 4 lines

Actually I just got a chance to start on a review of things. Do we need to have to use both GSO_UDP and and GSO_UDP_L4? It might be better if we could split these up and specifically call out GSO_UDP as UFO and GSO_UDP_L4 as being UDP segmentation.

Thanks for taking a look, Alex.

Agreed, I'll revise that. My initial thought was that both gso skbs need to take the same udp gso special case branches in places like act_csum and ovs. But on rereading that seems an unsafe approach, as some branches are fragmentation specific. I'll review them all and add separate SKB_GSO_UDP_L4 cases where needed, instead.

My only concern with the patch set is verifying what mitigations are in case so that we aren't trying to set an MSS size that results in a frame larger than MTU. I'm still digging through the code and trying to grok it, but I figured I might just put the question out there to may my reviewing easier.

Quoted 21 lines · David Miller

From: Sowmini Varadhan <[email protected]>
Date: Wed, 18 Apr 2018 08:31:03 -0400

Quoted 8 lines

However, I share Sridhar's concerns about the very fundamental change to UDP message boundary semantics here. There is actually no such thing as a "segment" in udp, so in general this feature makes me a little uneasy. Well behaved udp applications should already be sending mtu sized datagrams. And the not-so-well-behaved ones are probably relying on IP fragmentation/reassembly to take care of datagram boundary semantics for them?

Quoted 4 lines

As Sridhar points out, the feature is not really "negotiated" - one side unilaterally sets the option. If the receiver is a classic/POSIX UDP implementation, it will have no way of knowing that message boundaries have been re-adjusted at the sender.

There are no "semantics".

What ends up on the wire is the same before the kernel/app changes as afterwards.

Quoted 6 lines

The only difference is that instead of the application doing N - 1 sendmsg() calls with mtu sized writes, it's giving everything all at once and asking the kernel to segment.

It even gives the application control over the size of the packets, which I think is completely prudent in this situation.

My only concern with the patch set is verifying what mitigations are in case so that we aren't trying to set an MSS size that results in a frame larger than MTU. I'm still digging through the code and trying to grok it, but I figured I might just put the question out there to may my reviewing easier.

Also any plans for HW offload support for this? I vaguely recall that the igb and ixgbe parts had support for something like this in hardware. I would have to double check to see what exactly is supported.

Thanks.

- Alex

Quoted 41 lines · Alexander Duyck

Quoted 24 lines · David Miller

From: Sowmini Varadhan <[email protected]>
Date: Wed, 18 Apr 2018 08:31:03 -0400

Quoted 9 lines

However, I share Sridhar's concerns about the very fundamental change to UDP message boundary semantics here. There is actually no such thing as a "segment" in udp, so in general this feature makes me a little uneasy. Well behaved udp applications should already be sending mtu sized datagrams. And the not-so-well-behaved ones are probably relying on IP fragmentation/reassembly to take care of datagram boundary semantics
for them?

Quoted 4 lines

As Sridhar points out, the feature is not really "negotiated" - one side unilaterally sets the option. If the receiver is a classic/POSIX UDP implementation, it will have no way of knowing that message boundaries have been re-adjusted at the sender.

There are no "semantics".

What ends up on the wire is the same before the kernel/app changes as afterwards.

Quoted 6 lines

The only difference is that instead of the application doing N - 1 sendmsg() calls with mtu sized writes, it's giving everything all at once and asking the kernel to segment.

It even gives the application control over the size of the packets, which I think is completely prudent in this situation.

My only concern with the patch set is verifying what mitigations are in case so that we aren't trying to set an MSS size that results in a frame larger than MTU. I'm still digging through the code and trying to grok it, but I figured I might just put the question out there to may my reviewing easier.

Quoted 4 lines

Also any plans for HW offload support for this? I vaguely recall that the igb and ixgbe parts had support for something like this in hardware. I would have to double check to see what exactly is supported.

Alex,

If by HW support you meant UFO (UDP Fragmentation Offload), then I have dig into that last year using ixgbe. And I found that Intel 10G HW does break large UDP packets into MTU size however it does not generate *true* IP fragments. Instead, when large (> MTU) size UDP packet is given to NIC, HW generates unique UDP packets with distinct IP fragments. This makes it impossible for receiving station to reassemble them into one UDP packet.

I am not sure about igb!

-Tushar

Quoted 60 lines · Tushar Dave

Quoted 41 lines · Alexander Duyck

Quoted 24 lines · David Miller

From: Sowmini Varadhan <[email protected]>
Date: Wed, 18 Apr 2018 08:31:03 -0400

Quoted 9 lines

However, I share Sridhar's concerns about the very fundamental change to UDP message boundary semantics here. There is actually no such thing as a "segment" in udp, so in general this feature makes me a little uneasy. Well behaved udp applications should already be sending mtu sized datagrams. And the not-so-well-behaved ones are probably relying on IP fragmentation/reassembly to take care of datagram boundary semantics
for them?

Quoted 4 lines

As Sridhar points out, the feature is not really "negotiated" - one side unilaterally sets the option. If the receiver is a classic/POSIX UDP implementation, it will have no way of knowing that message boundaries have been re-adjusted at the sender.

There are no "semantics".

What ends up on the wire is the same before the kernel/app changes as afterwards.

Quoted 6 lines

The only difference is that instead of the application doing N - 1 sendmsg() calls with mtu sized writes, it's giving everything all at once and asking the kernel to segment.

It even gives the application control over the size of the packets, which I think is completely prudent in this situation.

My only concern with the patch set is verifying what mitigations are in case so that we aren't trying to set an MSS size that results in a frame larger than MTU. I'm still digging through the code and trying to grok it, but I figured I might just put the question out there to may my reviewing easier.

Quoted 4 lines

Also any plans for HW offload support for this? I vaguely recall that the igb and ixgbe parts had support for something like this in hardware. I would have to double check to see what exactly is supported.

Alex,

If by HW support you meant UFO (UDP Fragmentation Offload), then I have dig into that last year using ixgbe. And I found that Intel 10G HW does break large UDP packets into MTU size however it does not generate *true* IP fragments. Instead, when large (> MTU) size UDP packet is given to NIC, HW generates unique UDP packets with distinct IP fragments. This makes it impossible for receiving station to reassemble them into one UDP packet.

Quoted 3 lines

I am not sure about igb!

-Tushar

Tushar,

I am not sure you have been following this thread, but this is about adding UDP GSO support, not fragmentation offload. With GSO support the UDP frames are not expected to be reassembled they are meant to be handled as individual frames.

What you have described is why I am interested. This patch set adds support for GSO segmentation, not fragmentation.

Thanks.

- Alex

That said, for negotiated flows an inverse GRO feature could conceivably be implemented to reduce rx stack traversal, too. Though due to interleaving of packets on the wire, it aggregation would be best effort, similar to TCP TSO and GRO using the PSH bit as packetization signal.

I hope quic can leverage such scenario, but I
really know nothing about the protocol.

Hi,

Quoted 5 lines · Willem de Bruijn

That said, for negotiated flows an inverse GRO feature could conceivably be implemented to reduce rx stack traversal, too. Though due to interleaving of packets on the wire, it aggregation would be best effort, similar to TCP TSO and GRO using the PSH bit as packetization signal.

Reviving this old thread, before I forgot again. I have some local patches implementing UDP GRO in a dual way to current GSO_UDP_L4
implementation: several datagram with the same length are aggregated into a single one, and the user space receive a single larger packet instead of multiple ones. I hope quic can leverage such scenario, but I really know nothing about the protocol.

I measure roughly a 50% performance improvement with udpgso_bench in respect to UDP GSO, and ~100% using a pktgen sender, and a reduced CPU usage on the receiver[1]. Some additional hacking to the general GRO bits is required to avoid useless socket lookups for ingress UDP packets when UDP_GSO is not enabled.

If there is interest on this topic, I can share some RFC patches (hopefully somewhat next week).

Quoted 17 lines · Paolo Abeni

Hi,

Quoted 5 lines · Willem de Bruijn

That said, for negotiated flows an inverse GRO feature could conceivably be implemented to reduce rx stack traversal, too. Though due to interleaving of packets on the wire, it aggregation would be best effort, similar to TCP TSO and GRO using the PSH bit as packetization signal.

Reviving this old thread, before I forgot again. I have some local patches implementing UDP GRO in a dual way to current GSO_UDP_L4
implementation: several datagram with the same length are aggregated into a single one, and the user space receive a single larger packet instead of multiple ones. I hope quic can leverage such scenario, but I really know nothing about the protocol.

Quoted 8 lines

I measure roughly a 50% performance improvement with udpgso_bench in respect to UDP GSO, and ~100% using a pktgen sender, and a reduced CPU usage on the receiver[1]. Some additional hacking to the general GRO bits is required to avoid useless socket lookups for ingress UDP packets when UDP_GSO is not enabled.

If there is interest on this topic, I can share some RFC patches (hopefully somewhat next week).

As Eric pointed out, QUIC reception on mobile clients over the WAN may not see much gain. But apparently there is a non-trivial amount of traffic the other way, to servers. Again, WAN might limit whatever gain we get, but I do want to look into that. And there are other UDP high throughput workloads (with or without QUIC) between servers.

If you have patches, please do share them.

I actually also have a rough
patch that I did not consider ready to share yet. Based on Tom's existing socket lookup in udp_gro_receive to detect whether a local destination exists and whether it has set an option to support receiving coalesced payloads (along with a cmsg to share the segment size).

Converting udp_recvmsg to split apart gso packets to make this transparent seems to me to be too complex and not worth the effort.

If a local socket is not found in udp_gro_receive, this could also be tentative interpreted as a non-local path (with false positives), enabling transparent use of GRO + GSO batching on the forwarding path.

Quoted 27 lines · Willem de Bruijn

Quoted 17 lines · Paolo Abeni

Hi,

Quoted 5 lines · Willem de Bruijn

That said, for negotiated flows an inverse GRO feature could conceivably be implemented to reduce rx stack traversal, too. Though due to interleaving of packets on the wire, it aggregation would be best effort, similar to TCP TSO and GRO using the PSH bit as packetization signal.

Reviving this old thread, before I forgot again. I have some local patches implementing UDP GRO in a dual way to current GSO_UDP_L4
implementation: several datagram with the same length are aggregated into a single one, and the user space receive a single larger packet instead of multiple ones. I hope quic can leverage such scenario, but I really know nothing about the protocol.

Quoted 8 lines

I measure roughly a 50% performance improvement with udpgso_bench in respect to UDP GSO, and ~100% using a pktgen sender, and a reduced CPU usage on the receiver[1]. Some additional hacking to the general GRO bits is required to avoid useless socket lookups for ingress UDP packets when UDP_GSO is not enabled.

If there is interest on this topic, I can share some RFC patches (hopefully somewhat next week).

Quoted 7 lines

As Eric pointed out, QUIC reception on mobile clients over the WAN may not see much gain. But apparently there is a non-trivial amount of traffic the other way, to servers. Again, WAN might limit whatever gain we get, but I do want to look into that. And there are other UDP high throughput workloads (with or without QUIC) between servers.

If you have patches, please do share them.

I'll try to clean them up and send them next week (as RFC).

Quoted 5 lines

I actually also have a rough
patch that I did not consider ready to share yet. Based on Tom's existing socket lookup in udp_gro_receive to detect whether a local destination exists and whether it has set an option to support receiving coalesced payloads (along with a cmsg to share the segment size).

That is more or less what I'm doing here.
Side note: I had test it in baremetal, as veth/lo do not trigger the GRO path: selftest of this feature is not so straightforward.

Quoted 2 lines

Converting udp_recvmsg to split apart gso packets to make this transparent seems to me to be too complex and not worth the effort.

Agreed. Moreover doing many, small, recvmsg() instead of a single, large, one will hit the performances very badly due to PTI and HARDENED_USERCOPY.

Quoted 3 lines

If a local socket is not found in udp_gro_receive, this could also be tentative interpreted as a non-local path (with false positives), enabling transparent use of GRO + GSO batching on the forwarding path.

That sounds interesting, even if false positive looks dangerous to me. Just to be on the same page, which false positive examples are you thinking at? UDP sockets bound to local address behind NAT?

Quoted 17 lines · Paolo Abeni

Hi,

Quoted 5 lines · Willem de Bruijn

That said, for negotiated flows an inverse GRO feature could conceivably be implemented to reduce rx stack traversal, too. Though due to interleaving of packets on the wire, it aggregation would be best effort, similar to TCP TSO and GRO using the PSH bit as packetization signal.

Reviving this old thread, before I forgot again. I have some local patches implementing UDP GRO in a dual way to current GSO_UDP_L4
implementation: several datagram with the same length are aggregated into a single one, and the user space receive a single larger packet instead of multiple ones. I hope quic can leverage such scenario, but I really know nothing about the protocol.

Quoted 8 lines

I measure roughly a 50% performance improvement with udpgso_bench in respect to UDP GSO, and ~100% using a pktgen sender, and a reduced CPU usage on the receiver[1]. Some additional hacking to the general GRO bits is required to avoid useless socket lookups for ingress UDP packets when UDP_GSO is not enabled.

If there is interest on this topic, I can share some RFC patches (hopefully somewhat next week).

As Eric pointed out, QUIC reception on mobile clients over the WAN may not see much gain. But apparently there is a non-trivial amount of traffic the other way, to servers. Again, WAN might limit whatever gain we get, but I do want to look into that. And there are other UDP high throughput workloads (with or without QUIC) between servers.

If you have patches, please do share them. I actually also have a rough patch that I did not consider ready to share yet. Based on Tom's existing socket lookup in udp_gro_receive to detect whether a local destination exists and whether it has set an option to support receiving coalesced payloads (along with a cmsg to share the segment size).

Converting udp_recvmsg to split apart gso packets to make this transparent seems to me to be too complex and not worth the effort.

If a local socket is not found in udp_gro_receive, this could also be tentative interpreted as a non-local path (with false positives), enabling transparent use of GRO + GSO batching on the forwarding path.

I'm working on patches that builds such skb lists. The list is chained at the frag_list pointer of the first skb, all subsequent skbs are linked to the next pointer of the skb. It looks like this:

From: Willem de Bruijn <[email protected]>

Segmentation offload reduces cycles/byte for large packets by amortizing the cost of protocol stack traversal.

This patchset implements GSO for UDP. A process can concatenate and submit multiple datagrams to the same destination in one send call by setting socket option SOL_UDP/UDP_SEGMENT with the segment size, or passing an analogous cmsg at send time.

The stack will send the entire large (up to network layer max size) datagram through the protocol layer. At the GSO layer, it is broken up in individual segments. All receive the same network layer header and UDP src and dst port. All but the last segment have the same UDP header, but the last may differ in length and checksum.

Quoted 10 lines · Willem de Bruijn

From: Willem de Bruijn <[email protected]>

Segmentation offload reduces cycles/byte for large packets by amortizing the cost of protocol stack traversal.

This patchset implements GSO for UDP. A process can concatenate and submit multiple datagrams to the same destination in one send call by setting socket option SOL_UDP/UDP_SEGMENT with the segment size, or passing an analogous cmsg at send time.

Quoted 5 lines

The stack will send the entire large (up to network layer max size) datagram through the protocol layer. At the GSO layer, it is broken up in individual segments. All receive the same network layer header and UDP src and dst port. All but the last segment have the same UDP header, but the last may differ in length and checksum.

This is interesting, thanks for sharing!

I have some local patches somewhere implementing UDP GRO, but I never tried to upstream them, since I lacked the associated GSO and I thought that the use-case was not too relevant.

Given that your use-case is a connected socket - no per packet route lookup - how does GSO performs compared to plain sendmmsg()? Have you considered using and/or improving the latter?

When testing with Spectre/Meltdown mitigation in places, I expect that the most relevant part of the gain is due to the single syscall per burst.

I just hacked up a sendmmsg extension to the benchmark to verify. Indeed that does not have nearly the same benefit as GSO:

udp tx: 976 MB/s 695394 calls/s 16557 msg/s

This matches the numbers seen from TCP without TSO and GSO. That also has few system calls, but observes per MTU stack traversal.

Quoted 7 lines · Willem de Bruijn

I just hacked up a sendmmsg extension to the benchmark to verify. Indeed that does not have nearly the same benefit as GSO:

udp tx: 976 MB/s 695394 calls/s 16557 msg/s

This matches the numbers seen from TCP without TSO and GSO. That also has few system calls, but observes per MTU stack traversal.

Reviving this old thread because it's the only place I saw sendmmsg being mentioned.

sendmmsg shouldn't be considered as an alternative, but rather as a complement. Then instead of the application building one large request and request the stack to fragment it, it could simply build the sendmmsg request and the stack would group the mmsg into a gso skb. It seems more natural to the application. But well, both (sendmmsg and the option to fragment) are Linux-specific..

For that we need sendmmsg to do something smarter than doing several sendmsg calls, yes.

When testing with Spectre/Meltdown mitigation in places, I expect that the most relevant part of the gain is due to the single syscall per burst.

Segmentation offload reduces cycles/byte for large packets by amortizing the cost of protocol stack traversal.

This patchset implements GSO for UDP.

From: Willem de Bruijn <[email protected]>
Date: Tue, 17 Apr 2018 16:00:50 -0400

Quoted 4 lines

Segmentation offload reduces cycles/byte for large packets by amortizing the cost of protocol stack traversal.

This patchset implements GSO for UDP.

This looks great.

And as mentioned in other emails, the interface looks good too by letting the app choose the segmentation point.

It's a real shame we lose checksumming with MSG_MORE, perhaps we can find a way to lift that restriction?

Actually, yes, I should be able to relax that constraint with segmentation.

It is there in case a corked packet may grow to the point of having to be fragmented. But segmentation already ensures that its datagrams always fit in MTU.

Should be simple refinement to

            !(flags & MSG_MORE) &&

in __ip_append_data.