On Tue, Oct 26, 2021 at 01:37:14PM +0800, Jason Wang wrote: > > 在 2021/10/22 下午1:19, Mike Christie 写道: > > This patch allows userspace to create workers and bind them to vqs. You > > can have N workers per dev and also share N workers with M vqs. > > > > Signed-off-by: Mike Christie <michael.christie@xxxxxxxxxx> > > > A question, who is the best one to determine the binding? Is it the VMM > (Qemu etc) or the management stack? If the latter, it looks to me it's > better to expose this via sysfs? A few options that let the management stack control vhost worker CPU affinity: 1. The management tool opens the vhost device node, calls ioctl(VHOST_SET_VRING_WORKER), sets up CPU affinity, and then passes the fd to the VMM. In this case the VMM is still able to call the ioctl, which may be undesirable from an attack surface perspective. 2. The VMM calls ioctl(VHOST_SET_VRING_WORKER) itself and the management tool queries the vq:worker details from the VMM (e.g. a new QEMU QMP query-vhost-workers command similar to query-iothreads). The management tool can then control CPU affinity on the vhost worker threads. (This is how CPU affinity works in QEMU and libvirt today.) 3. The sysfs approach you suggested. Does sysfs export vq-0/, vq-1/, etc directories with a "worker" attribute? Do we need to define a point when the VMM has set up vqs and the management stack is able to query them? Vhost devices currently pre-allocate the maximum number of vqs and I'm not sure how to determine the number of vqs that will actually be used? One advantage of this is that access to the vq:worker mapping can be limited to the management stack and the VMM cannot access it. But it seems a little tricky because the vhost model today doesn't use sysfs or define a lifecycle where the management stack can configure devices. Stefan
Attachment:
signature.asc
Description: PGP signature
