Messages in this thread | | | Date | Mon, 24 Aug 2009 14:02:09 -0500 | From | Anthony Liguori <> | Subject | Re: vbus design points: shm and shm-signals |
| |
Gregory Haskins wrote: > Gregory Haskins wrote: > >> Ingo Molnar wrote: >> >>> We all love faster code and better management interfaces and tons >>> of your prior patches got accepted by Avi. This time you didnt even >>> _try_ to improve virtio. >>> >> Im sorry, but you are mistaken: >> >> http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/02443.html >> >> > > BTW: One point that I forgot to point out in this most recent thread > that I am particularly proud of here is the design of the vbus > shared-memory model. Despite some claims to the contrary; not only is > it possible to improve virtio with vbus (as evident by the patch > referenced above)...I specifically designed vbus with virtio > considerations in mind from the start! In fact, the design is conducive > to accelerating a variety of other models as well. Read on for details. > > Vbus was designed it to be _agnostic_ to the shm algorithm in general. > This allows you to, of course, run ring algorithms (such as virtqueues, > or IOQs), but really any other designs as well, such as shared-tables, etc. > > A guest driver sees the following interface: > > struct vbus_device_proxy_ops { > int (*open)(struct vbus_device_proxy *dev, int version, int flags); > int (*close)(struct vbus_device_proxy *dev, int flags); > int (*shm)(struct vbus_device_proxy *dev, int id, int prio, > void *ptr, size_t len, > struct shm_signal_desc *sigdesc, struct shm_signal **signal, > int flags); > int (*call)(struct vbus_device_proxy *dev, u32 func, > void *data, size_t len, int flags); > void (*release)(struct vbus_device_proxy *dev); > }; > > note the ops->shm() method. This allows the driver to register some > arbitrary pointer (ptr, len) with the host, optionally embedding a > shm_signal_desc object in the memory. If "sigdesc" is non-null, the > connector will allocate and return a fully formed shm_signal object in > **signal. >
Fundamentally, how is this different than the virtio->add_buf concept?
virtio provides a mechanism to register scatter/gather lists, associate a handle with them, and provides a mechanism for retrieving notification that the buffer has been processed.
vbus provides a mechanism to register a single buffer with an integer handle, priority, and a signaling mechanism.
So virtio provides builtin support for scatter/gathers whereas vbus models priority. But fundamentally, they seem like almost identical concepts.
If we added priority to virtio->add_buf, would it be equivalent in your mind functionally speaking?
What does one do with priority, btw?
Is there something I'm overlooking?
Regards,
Anthony Liguroi
| |