5x Kernel for UDP improvements

mk150 · 15 April 2023 06:28

Just curious when OSMC/Vero 4K might shift to a 5x kernel?

Asking in relation to some UDP improvements that will affect Tailscale soon (and in the future upstream Wireguard)… but may also help with throughput for other applications too.

Ref:

Specifically these features:
UDP-GSO - Merge branch 'udp-gso' · torvalds/linux@cb586c6 · GitHub
UDP-GRO - Merge branch 'udp-gro' · torvalds/linux@cab6949 · GitHub

sam_nazarko · 16 April 2023 00:07

Hi,

I don’t plan to upgrade the Vero 4K to a 5.x kernel.
It’s approaching 7 years

We are working on upstream support with others, so you’ll be able to use upstream kernels in the future.

We will stay with 4.9.269 and we will maintain this kernel for some time.
Launch the next device on 4.9.269, then move to 5.4 shortly and 5.18 after that.

Can you explain your use-case?
I’ll see what can be backported.

mk150 · 16 April 2023 03:41

Thanks for the reply @sam_nazarko

That’s interesting to know about the future kernel plans.

Any difference with the 4K+ ? It seems surprising that you wouldn’t try to keep all the devices on a similar or the same kernel.

My use case is: I use Tailscale on a couple of Vero 4K+ devices so they can connect back directly to my NAS (even when not connected to the same network). Tailscale works brilliantly for this, though I have noticed that while it works fine for 1080p content, it taxes the CPU a bit on the 4K+. I was hoping these improvements would be supported on the Vero to help improve the transfer efficiency/lower the system load.

I also figured these improvements may also help improve other UDP transfers, e.g. over direct UDP NFS mounts?

If these sorts of improvements could be reliably back-ported, that’d be great.

sam_nazarko · 16 April 2023 11:09

We keep the same kernel for 4K and 4K + devices. All that’s different between them is the Device Tree structure used when booting.

mk150 · 28 April 2023 04:18

Given no newer kernel release for the 4K/4K+, any chance you might be able to back-port these improvements @sam_nazarko ?

While I’m up for purchasing the new device when it comes out (and I will), I still really appreciate these UDP improvements for Tailscale on the 2 4K+ I have. Tailscale have now released a new version that takes advantage of these features (Release 1.40.0 · tailscale/tailscale · GitHub)

Thanks

sam_nazarko · 1 May 2023 02:22

I’ll take a look and see how feasible it is.

If you can break it down in to the original commits and not just the whole branch it would be helpful.

mk150 · 1 May 2023 09:29

Thanks @sam_nazarko, though I’m afraid I’m not clueful enough to figure out the exact commits. I thought that was what I linked to

mk150 · 18 December 2023 03:37

@sam_nazarko Tailscale just recently made some further related enhancements, see this article:

I did sift through these few articles and they had links to most of the original commits for the changes - perhaps this might enable you to back-port these changes sometime.

github.com/torvalds/linux

Merge branch 'udp-gso'

committed 07:10PM - 26 Apr 18 UTC

davem330

+1687 -51

Willem de Bruijn says: ==================== udp gso Segmentation offload reduc…es 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. Initial results show a significant reduction in UDP cycles/byte. See the main patch for more details and benchmark results. udp 876 MB/s 14873 msg/s 624666 calls/s 11,205,777,429 cycles udp gso 2139 MB/s 36282 msg/s 36282 calls/s 11,204,374,561 cycles The patch set is broken down as follows: - patch 1 is a prerequisite: code rearrangement, noop otherwise - patch 2 implements the gso logic - patch 3 adds protocol stack support for UDP_SEGMENT - patch 4,5,7 are refinements - patch 6 adds the cmsg interface - patch 8..11 are tests This idea was presented previously at netconf 2017-2 http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf Changes v1 -> v2 - Convert __udp_gso_segment to modify headers after skb_segment - Split main patch into two, one for gso logic, one for UDP_SEGMENT Changes RFC -> v1 - MSG_MORE: fixed, by allowing checksum offload with corking if gso - SKB_GSO_UDP_L4: made independent from SKB_GSO_UDP and removed skb_is_ufo() wrapper - NETIF_F_GSO_UDP_L4: add to netdev_features_string and to netdev-features.txt add BUILD_BUG_ON to match SKB_GSO_UDP_L4 value - UDP_MAX_SEGMENTS: introduce limit on number of segments per gso skb to avoid extreme cases like IP_MAX_MTU/IPV4_MIN_MTU - CHECKSUM_PARTIAL: test against missing feature after ndo_features_check if not supported return error, analogous to udp_send_check - MSG_ZEROCOPY: removed, deferred for now ==================== Signed-off-by: David S. Miller <davem@davemloft.net>

github.com/torvalds/linux

Merge branch 'udp-gro'

committed 12:23AM - 08 Nov 18 UTC

davem330

+708 -123

Paolo Abeni says: ==================== udp: implement GRO support This series …implements GRO support for UDP sockets, as the RX counterpart of commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT"). The core functionality is implemented by the second patch, introducing a new sockopt to enable UDP_GRO, while patch 3 implements support for passing the segment size to the user space via a new cmsg. UDP GRO performs a socket lookup for each ingress packets and aggregate datagram directed to UDP GRO enabled sockets with constant l4 tuple. UDP GRO packets can land on non GRO-enabled sockets, e.g. due to iptables NAT rules, and that could potentially confuse existing applications. The solution adopted here is to de-segment the GRO packet before enqueuing as needed. Since we must cope with packet reinsertion after de-segmentation, the relevant code is factored-out in ipv4 and ipv6 specific helpers and exposed to UDP usage. While the current code can probably be improved, this safeguard ,implemented in the patches 4-7, allows future enachements to enable UDP GSO offload on more virtual devices eventually even on forwarded packets. The last 4 for patches implement some performance and functional self-tests, re-using the existing udpgso infrastructure. The problematic scenario described above is explicitly tested. This revision of the series try to address the feedback provided by Willem and Subash on previous iteration. ==================== Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>

https://lwn.net/Articles/883713/

sam_nazarko · 18 December 2023 11:38

Won’t do any more back porting as we will move to 5.15 in the near future

Cheers
Sam