Date: Wed, 10 Feb 2021 18:08:57 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 237441] Virtio net consistently truncates last byte of a fetch xfer with > 8956 bytes of payload Message-ID: <bug-237441-7501-aDcKMgVwgH@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-237441-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-237441-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237441 Adam Chappell <adam.chappell@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adam.chappell@gmail.com --- Comment #9 from Adam Chappell <adam.chappell@gmail.com> --- Would be intrigued to understand what the FreeBSD fix was here. Doesn't see= m to be in release notes. I believe this issue is not an issue with the FreeBSD guest but more likely an issue with the MacOS/Darwin poll() returning POLLP= RI events to Qemu's userland TCP stack, Slirp. When Slirp sees POLLPRI on a TCP stream it assumes (not unreasonably) that the incoming data has some urgent data in it. It makes some effort to craft a TCP segment=20 for the guest with URG flag and pointer set to a best guess. Unfortunately the guest VM's read() won't return urgent/OOB data in normal operation. As a result, data is omitted. >From my tests it seems very prevalent that MacOS poll() returns POLLPRI on = the last segment (perhaps it's signalling POLLPRI to tell the reader that the stream has finished?), which does explain why we lose the last byte or so. Lopping out the (revents & SLIRP_POLL_PRI) clause in slirp.c:slirp_pollfds_poll() in favour of the subsequent else-if makes things work, at the cost of NOPing out Slirp's likely hapless attempt= s to do URG reconstruction. RFC6093 seems to push us away from ever using TCP urgent in new apps, so ma= ybe that's not as bad as it seems. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237441-7501-aDcKMgVwgH>