On 2/9/21 10:08 AM, Richard W.M. Jones wrote: > On Tue, Feb 09, 2021 at 09:27:58AM -0600, Eric Blake wrote: >> 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 Unix, a
s/where on Unix/where on Linux/ >> 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 <rjo...@redhat.com> >> Signed-off-by: Eric Blake <ebl...@redhat.com> >> CC: qemu-sta...@nongnu.org >> --- >> blockdev-nbd.c | 7 ++++++- >> qemu-nbd.c | 10 +++++++++- >> 2 files changed, 15 insertions(+), 2 deletions(-) >> > > Works fine here, so: > > Tested-by: Richard W.M. Jones <rjo...@redhat.com> > Thanks for testing. > Rich. > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org