qemu-nbd: Use SOMAXCONN for socket listen() backlog
authorEric Blake <eblake@redhat.com>
Tue, 9 Feb 2021 15:27:58 +0000 (09:27 -0600)
committerSoonKyu Park <sk7.park@samsung.com>
Tue, 23 Nov 2021 04:45:31 +0000 (13:45 +0900)
commit396870f44b3821443e30ffc26afa2acb5631778a
tree6793792f703e9195797c46ae29f42ecc7f73a1fc
parent75e797be88d0668342df7774f3c6e21c066768e0
qemu-nbd: Use SOMAXCONN for socket listen() backlog

Git-commit: 582d4210eb2f2ab5baac328fe4b479cd86da1647

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>
Signed-off-by: Bruce Rogers <brogers@suse.com>
blockdev-nbd.c
qemu-nbd.c