On Sun, Nov 4, 2018 at 9:52 PM Jason Wang <jasowang@xxxxxxxxxx> wrote: > Thanks a lot for the patches. Here's some thoughts: > > - This is not the first attempt that tries to parallelize vhost workers. > So we need a comparing among them. > > 1) Multiple vhost workers from Anthony, > https://www.spinics.net/lists/netdev/msg189432.html > > 2) ELVIS from IBM, http://www.mulix.org/pubs/eli/elvis-h319.pdf > > 3) CMWQ from Bandan, > http://www.linux-kvm.org/images/5/52/02x08-Aspen-Bandan_Das-vhost-sharing_is_better.pdf > > - vhost-net use a different multiqueue model. Each vhost device on host > is only dealing with a specific queue pair instead of a whole device. > This allow great flexibility and multiqueue could be implemented without > touching vhost codes. I'm no way a network expert, but I think this is because it follows a combined queue model of the NIC. Having a TX/RX queues pair looks like a natural choice for this case. > - current vhost-net implementation depends heavily on the assumption of > single thread model especially its busy polling code. It would be broken > by this attempt. If we decide to go this way, this needs to be fixed. > And we do need performance result of networking. Thanks for noting that, I miss a lot of historical background. Will check that up. > - Having more threads is not necessarily a win, at least we need a > module parameter to other stuffs to control the number of threads I > believe. I agree I didn't think fully about other cases, but for the disk it is already under controll: QEMU's num-queues disk parameter. There's a certain saturation point when adding more threads does not yield lot more more performance. For my environment it's about 12 queues. So, how does it sound: the default behaviour is 1 worker per vhost device. If the user needs per-vq worker he does a new VHOST_SET_ ioctl? -- wbr, Vitaly
