Re: [virtio-comment] RE: [virtio] Minutes for 2014-03-11 Oasis VIRTIO TC call

[Rusty Russell <rusty@au1.ibm.com>]

RAUCHFUSS Holm <holm.rauchfuss@huawei.com> writes:
>> From: Paul Mundt
>> 
>> On 2014年3月11日 14:30 午後, Pawel Moll wrote:
>> >     VIRTIO-60 vring*, VRING_* and virtio_ring used for virtqueue
>> > without explanation
>> >
>> > Accepted, to be followed up in a new issue to clarify, proposed by
>> > Rusty, seconded by Pawel, no objections
>> >
>> Regarding this issue, Holm (who raised the initial objection to Rusty's
>> patch) was unable to attend the meeting and did not voice any
>> objections to me about it in advance, but in our discussion afterwards
>> has mentioned a few issues of concern that I have asked him to post to
>> the comment list for follow-up.
>> 
>> As this change introduces a fair bit of churn, perhaps we could instead
>> defer this until those issues are addressed or rejected in order to
>> avoid the potential for a messy revert later on? Obviously as this has
>> already passed we can handle the revert scenario too for the third
>> draft if it becomes necessary.
>
> My initial comment/intention was a) to avoid the confusion we have right now between virtqueue and virtio_ring and b) to have the option to realize virtqueue maybe with a different/modified in-memory-layout structure than virtio_ring.

Indeed, this separation of concept and implementation was in the initial
Linux implementation.  It has been slowly removed: after 5 years it was
still unused.

> Regarding a): We would essentially break the whole abstraction in all
> existing code out there. It was my understanding that the virtio
> specification should provide a formalized text for what has been
> created in the last years. I think it is fine if the standardization
> process "fixes" certain corner cases and clarifies use cases. But
> modifying a central part of virtio in that way probably will not help
> the adoption of the standard.

There is always a tension between existing and future implementations.
From our charter:

        Our goal is to keep the good, discard the bad, and make the ugly
        optional. In particular, we will try not to break too much, and
        ensure it's possible for devices to support both 1.0 compliant
        and legacy guest drivers.

Removing an unused abstraction is a clear clarity gain, which is why the
feedback was given.

This spec change doesn't add any new requirements to an implementation;
it can continue to use the old names if it wants.  We've made more
significant changes which (at least for Linux) affect implementation far
more.

> Regarding b): Reason for that is that we are currently investigating
> virtio as an abstraction for message passing. Most of the times
> virtio_ring is enough/efficient to move the bits here. But for
> low-latency interactions we maybe have to switch to a different
> in-memory-layout which can still be abstracted by virtqueue. As one
> potential alternative I refer to the memory layout of Barrelfish for
> message passing: http://www.barrelfish.org/TN-011-IDC.pdf (chapter
> 5.2). In the moment virtqueue and virtio_ring are merged and the new
> virtqueue is set as only standard we are blocked from doing this. With
> just the modification Paul mentioned initially we would have there
> more flexibility.

There has been no suggestion that virtio v1.0 would have an alternate
queue mechanism.  In fact, this is the first I've heard of it!

If we add such a thing, the spec will need major rework anyway.
Assumptions about how the current queue operates are spread throughout
the spec (eg. the queue size parameter, implicit queue lengths).  And
since we don't know how it will change, we're certain to fail if we try
to adapt to it now.

Cheers,
Rusty.