From: Jakub Sitnicki <jakub@cloudflare.com>
To: Willem de Bruijn <willemb@google.com>
Cc: netdev@vger.kernel.org, kernel-team@cloudflare.com
Subject: EIO on send with UDP_SEGMENT
Date: Wed, 08 Nov 2023 11:58:57 +0100 [thread overview]
Message-ID: <87jzqsld6q.fsf@cloudflare.com> (raw)
Hi Willem et al,
We have hit the EIO error path in udp_send_skb introduced in commit bec1f6f69736
("udp: generate gso with UDP_SEGMENT") [0]:
if (skb->ip_summed != CHECKSUM_PARTIAL || ...) {
kfree_skb(skb);
return -EIO;
}
... when attempting to send a GSO packet, using UDP_SEGMENT option, from
a TUN device which didn't have any offloads enabled (the default case).
A trivial reproducer for that would be:
ip tuntap add dev tun0 mode tun
ip addr add dev tun0 192.0.2.1/24
ip link set dev tun0 up
strace -e %net python -c '
from socket import *
s = socket(AF_INET, SOCK_DGRAM)
s.setsockopt(SOL_UDP, 103, 1200)
s.sendto(b"x" * 3000, ("192.0.2.2", 9))
'
which yields:
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
setsockopt(3, SOL_UDP, UDP_SEGMENT, [1200], 4) = 0
sendto(3, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 3000, 0, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("192.0.2.2")}, 16) = -1 EIO (Input/output error)
This has been a surprise and caused us some pain. I think it comes down
to that anyone using UDP_SEGMENT has to implement a segmentation
fallback in user-space. Just to be on the safe side. We can't really
assume that any TUN/TAP interface, which happens to be our egress
device, has at least checksum offload enabled and implemented.
Which is not ideal.
So it made us wonder if anything can be done about it?
As it turns out, skb_segment() in GSO path implements a software
fallback not only for segmentation but also for checksumming [1].
What is more, when we removed the skb->ip_summed == CHECKSUM_PARTIAL
restriction in udp_send, as an experiment, we were able to observe fully
checksummed segments in packet capture.
Which brings me to my question -
Do you think the restriction in udp_send_skb can be lifted or tweaked?
Thanks,
Jakub
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bec1f6f697362c5bc635dacd7ac8499d0a10a4e7
[1] https://elixir.bootlin.com/linux/v6.6/source/net/core/skbuff.c#L4626
next reply other threads:[~2023-11-08 11:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 10:58 Jakub Sitnicki [this message]
2023-11-08 15:10 ` EIO on send with UDP_SEGMENT Willem de Bruijn
2023-11-08 17:55 ` Jakub Sitnicki
2023-11-08 19:11 ` Willem de Bruijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jzqsld6q.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=kernel-team@cloudflare.com \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).