Re: [PATCH 00/10] PV-IO v3

Gregory Haskins
2007-08-21T16:47:44Z

On Tue, 2007-08-21 at 10:06 -0400, Gregory Haskins wrote:
> On Tue, 2007-08-21 at 23:47 +1000, Rusty Russell wrote:
> >
> > In the guest -> host direction, an interface like virtio is designed
> > for batching, with the explicit distinction between add_buf & sync.
>
> Right. IOQ has "iter_push()" and "signal()" as synonymous operations.

Hi Rusty,
This reminded me of an area that I thought might have been missing in
virtio compared to IOQ. That is, flexibility in the io-completion via
the distinction between "signal" and "sync". sync() implies that its a
blocking call based on the full drain of the queue, correct? the
ioq_signal() operation is purely a "kick". You can, of course, still
implement synchronous functions with a higher layer construct such as
the ioq->wq. For example:

void send_sync(struct ioq *ioq, struct sk_buff *skb)
{
DECLARE_WAITQUEUE(wait, current);
struct ioq_iterator iter;

ioq_iter_init(ioq, &iter, ioq_idxtype_inuse, IOQ_ITER_AUTOUPDATE);

ioq_iter_seek(&iter, ioq_seek_head, 0, 0);

/* Update the iter.desc->ptr with skb details */

mb();
iter.desc->valid = 1;
iter.desc->sown = 1; /* give ownership to the south */
mb();

ioq_iter_push(&iter, 0);

add_wait_queue(&ioq->wq, &wait);
set_current_state(TASK_UNINTERRUPTIBLE);

/* Wait until we own it again */
while (!iter.desc->sown)
schedule();

set_current_state(TASK_RUNNING);
remove_wait_queue(&ioq->wq, &wait);
}

But really the goal behind this design was to allow for fine-grained
selection of how io-completion is notified. E.g. callback (e.g.
interrupt-driven) deferred reclaimation/reaping (see
ioqnet_tx_complete), sleeping-wait via ioq->wq, busy-wait, etc.

Is there a way to do something similar in virtio? (and forgive me if
there is..I still haven't seen the code). And if not and people like
that idea, what would be a good way to add it to the interface?

Regards,
-Greg