Re: [Libguestfs] [PATCH 1/1] nbd/server: push pending frames after sending reply

On Fri, Mar 24, 2023 at 02:41:20PM -0500, Eric Blake wrote: Replying to myself, WHY aren't we setting TCP_NODELAY on the socket? Corking matters more when TCP_NODELAY is enabled. The entire reason Nagle's algorithm exists (and is default on unless you enable TCP_NODELAY) is that the benefits of merging smaller piecemeal packets into larger traffic is a lot easier to do in a common location for code that isn't super-sensitive to latency and message boundaries. But once you get to the point where corking or MSG_MORE makes a difference, then it is obvious you know your message boundaries, and will benefit from TCP_NODELAY, at the expense of potentially more network traffic overhead. One more code search, and I find that we use TCP_NODELAY in all of: qemu client: https://gitlab.com/qemu-project/qemu/-/blob/master/nbd/client-connection.... nbdkit: https://gitlab.com/nbdkit/nbdkit/-/blob/master/server/sockets.c#L430 libnbd: https://gitlab.com/nbdkit/libnbd/-/blob/master/generator/states-connect.c... so I think we _should_ be calling qio_channel_set_delay(false) for qemu-nbd as well. That doesn't negate your patch, but rather argues that we can go for even better performance with TCP_NODELAY also turned on. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org