[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] RE: [virtio] Minutes for 2014-03-11 Oasis VIRTIO TC call
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]