OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

> 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). 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]