Re: vbus design points: shm and shm-signals

[Anthony Liguori]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/