qemu-nbd: Use SOMAXCONN for socket listen() backlog
commit582d4210eb2f2ab5baac328fe4b479cd86da1647
authorEric Blake <eblake@redhat.com>
Tue, 9 Feb 2021 15:27:58 +0000 (9 09:27 -0600)
committerEric Blake <eblake@redhat.com>
Fri, 12 Feb 2021 13:42:08 +0000 (12 07:42 -0600)
treeacb8a7a6326b9fd15e2ea5b3feb141ddd917847f
parenteac92d316351b855ba79eb374dd21cc367f1f9c1
qemu-nbd: Use SOMAXCONN for socket listen() backlog

Our default of a backlog of 1 connection is rather puny; it gets in
the way when we are explicitly allowing multiple clients (such as
qemu-nbd -e N [--shared], or nbd-server-start with its default
"max-connections":0 for unlimited), but is even a problem when we
stick to qemu-nbd's default of only 1 active client but use -t
[--persistent] where a second client can start using the server once
the first finishes.  While the effects are less noticeable on TCP
sockets (since the client can poll() to learn when the server is ready
again), it is definitely observable on Unix sockets, where on Linux, a
client will fail with EAGAIN and no recourse but to sleep an arbitrary
amount of time before retrying if the server backlog is already full.

Since QMP nbd-server-start is always persistent, it now always
requests a backlog of SOMAXCONN; meanwhile, qemu-nbd will request
SOMAXCONN if persistent, otherwise its backlog should be based on the
expected number of clients.

See https://bugzilla.redhat.com/1925045 for a demonstration of where
our low backlog prevents libnbd from connecting as many parallel
clients as it wants.

Reported-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
CC: qemu-stable@nongnu.org
Message-Id: <20210209152759.209074-2-eblake@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
blockdev-nbd.c
qemu-nbd.c