Re: [RFC] virtio: Support releasing lock during kick

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 23, 2010 at 10:24:02PM +0100, Stefan Hajnoczi wrote:
> The virtio block device holds a lock during I/O request processing.
> Kicking the virtqueue while the lock is held results in long lock hold
> times and increases contention for the lock.
> 
> This patch modifies virtqueue_kick() to optionally release a lock while
> notifying the host.  Virtio block is modified to pass in its lock.  This
> allows other vcpus to queue I/O requests during the time spent servicing
> the virtqueue notify in the host.
> 
> The virtqueue_kick() function is modified to know about locking because
> it changes the state of the virtqueue and should execute with the lock
> held (it would not be correct for virtio block to release the lock
> before calling virtqueue_kick()).
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>

While the optimization makes sense, the API's pretty hairy IMHO.
Why don't we split the kick functionality instead?
E.g.
	/* Report whether host notification is necessary. */
	bool virtqueue_kick_prepare(struct virtqueue *vq)
	/* Can be done in parallel with add_buf/get_buf */
	void virtqueue_kick_notify(struct virtqueue *vq)

And users can
	
	r = virtqueue_kick_prepare(vq);
	spin_unlock_irqrestore(...);
	if (r)
		virtqueue_kick_notify(struct virtqueue *vq)

-- 
MST