On Wed, Apr 02, 2025 at 09:20:33AM -0400, Stefan Hajnoczi wrote: > > > Eric: Are you interested in implementing support for multiple IOThreads > > > in the NBD export? I remember some time ago we talked about NBD > > > multi-conn support, although maybe that was for the client rather than > > > the server. > > > > The NBD server already supports clients that make requests through > > multiple TCP sockets, but right now, that server is not taking > > advantage of iothreads to spread the TCP load. > > > > And yes, I am in the middle of working on adding client NBD multi-conn > > support (reviving Rich Jones' preliminary patches on what it would > > take to have qemu open parallel TCP sockets to a supporting NBD > > server), which also will use a round-robin approach (but here, the > > round-robin is something we would code up in qemu, rather than the > > behavior handed to us by the FUSE kernel layer). Pinning specific > > iothreads to a specific TCP socket may or may not make sense, but I > > definitely want to have support for handing a pool of iothreads to an > > NBD client that will be using multi-conn. > > Here I'm asking Hanna to make the "iothreads" export parameter generic > for all export types (not just for FUSE). Do you think that the NBD > export will be able to use the generic parameter or would you prefer an > NBD-specific export parameter?
I would prefer to use a generic parameter. NBD will already need a specific parameter on whether to attempt to use multiple TCP sockets if the server advertises multi-conn. But how to map those TCP sockets to iothreads feels like a better fit for a generic iothreads; and perhaps the NBD parameter can also be made smart enough to auto-set the number of TCP sockets based on the number of available iothreads if there is no explicit override. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
