lkml.org 
[lkml]   [2009]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectvbus design points: shm and shm-signals
    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.

    shm-signal (posted in patch 1/6, I believe) is a generalization of the
    basic mechanism you need for emitting and catching events via any
    shared-memory based design. It includes interrupt/hypercall mitigation
    support which is independent of the actual shm algorithm (e.g. ring,
    table, etc). This means that we can get the event mitigation code (e.g.
    disable unecessary interrupts/hypercalls, prevent spurious re-calls,
    etc) in once place (and, ideally, correct), and things like the ring
    algorithm (or table design, etc) can focus on their value-add, instead
    of re-inventing the mitigation code each time.

    You can then build your higher-layer algorithms (rings, tables, etc) in
    terms of the shm-signal library. As a matter of fact, if you look at
    the patch referenced above, it implements the virtqueue->kick() method
    on top of shm-signal. IOQs follow a similar pattern. And the RT
    enhancements will, for instance, be using a table design for the
    scheduler/interrupt control.

    In short, vbus is the result of my experience in dealing with issues
    like IO in virt. I thought long and hard about where the issues were
    for high-performance, low-latency, software-to-software IO for a
    wide-variety of applications and environments. I then tried to
    systematically solve those problems at various key points in the stack
    to promote maximum flexibility and reuse of those enhancements. So we
    see things like this generalization of async event mitigation with the
    shm/shm-signal design, low-latency "hypercalls", reusable backend models
    (which support both a variety of virt, as well as physical system use), etc.

    Part of this flexibility means that we do not want to rely on something
    like PCI because it's not necessarily available/logical in all
    platforms/environments. So rather than force such environments to fit
    into a PCI ABI, we start over again and offer an ABI specific to the
    actual goals (high-performance, low-latency, software-to-software IO).

    Yes, that means we will possibly take some lumps in the short-term
    before these concepts and support for them are ubiquitous (like PCI, USB
    are today). But, like all things, you have to start somewhere. The PCI
    guys didn't try to make PCI look like ISA, and the USB guys didn't try
    to make USB look like PCI. It took a little while for support for such
    notions to catch on, but eventually all relevant platforms supported
    them. I am going for the same thing here. Sometimes, the existing
    model just doesn't fit well and you have to re-evaluate.

    I hope that this helps clarify some of the design of vbus and why I
    believe it to be worth considering. I will plan on taking this email as
    the first entry on the wiki as a "design series" (or something like
    that) and update it regularly with other aspects of the design.

    Kind Regards,
    -Greg





    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2009-08-21 12:59    [W:3.150 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site