lkml.org 
[lkml]   [2009]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2009-08-24 21:05    [W:0.201 / U:1.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site