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

Gregory Haskins
2007-08-21T14:06:02Z

On Tue, 2007-08-21 at 23:47 +1000, Rusty Russell wrote:

> Hi Gregory,
>
> The main current use is disk drivers: they process out-of-order.

Maybe for you ;) I am working on the networking/IVMC side.

>
> > I think the use of rings for the tx-path in of
> > itself is questionable unless you can implement something like the bidir
> > NAPI that I demonstrated in ioqnet. Otherwise, you end up having to
> > hypercall on each update to the ring anyway and you might as well
> > hypercall directly w/o using a ring.
>
> 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.
But note that batching via deferred synchronization does not implicitly
require a shared queue. E.g. you could batch internally and then
hypercall at the "sync" point. However, batching via a queue is still
nice because at least you give the host side a chance to independently
"notice" the changes concurrently before the sync. But I digress...

> On
> the receive side, you can have explicit interrupt suppression on
> implicit mitigation caused by scheduling effects.

Agreed. This is precisely what the bidir NAPI stuff is doing and I
didn't mean to imply that virtio wasn't capable of it too. All I meant
is that if you *don't* take advantage of it, the guest->host path via a
queue is likely overkill. E.g. you might as well hypercall instead.

> But in fact as we can see, two rings need less from each ring than one
> ring. One ring must have producer and consumer indices, so the producer
> doesn't overrun the consumer. But if the second ring is used to feed
> consumption, the consumer index isn't required any more: in fact, it's
> just confusing to have.

Don't get me wrong. I am totally in favor of the two ring approach.
You have enlightened me on that front. :) I was under the impression
that then making the two-ringed approach support out-of-order added
significantly more complexity. Did I understand that wrong?

>
> I really think that a table of descriptors, a ring for produced
> descriptors and a ring for used descriptors is the most cache-friendly,
> bidir-non-trusting simple implementation possible. Of course, the
> produced and used rings might be the same format, which allows code
> sharing and if you squint a little, that's your "lowest level" simple
> ringbuffer.

Sounds reasonable to me.

>
> Thanks for the discussion,

Ditto!
-Greg