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

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

On Tue, Mar 11, 2014 at 03:03:51PM +0000, RAUCHFUSS Holm wrote:
> > 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.
> 
> 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.
> 
> 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).

As far as I can see Barrelfish UMP assumes in-order completion of messages
and so would be inadequate for virtio.

> 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.
> 
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
> 
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> 
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/