From: Rusty Russell <rusty@rustcorp.com.au>
To: "Sjur Brændeland" <sjurbren@gmail.com>,
"Ohad Ben-Cohen" <ohad@wizery.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
virtualization <virtualization@lists.linux-foundation.org>,
Ido Yariv <ido@wizery.com>,
Erwan Yvin <erwan.yvin@stericsson.com>,
Dmitry Tarnyagin <dmitry.tarnyagin@stericsson.com>
Subject: Re: Wrappers for vringh (was Re: [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings))
Date: Thu, 28 Feb 2013 13:49:58 +1030 [thread overview]
Message-ID: <87txoxceg1.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAJK669Zdw+F8F8EUc__6rHscFdP4tCa8dDB+6LZ_abx2efyMHA@mail.gmail.com>
Sjur Brændeland <sjurbren@gmail.com> writes:
> On Fri, Feb 22, 2013 at 1:42 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> Ohad Ben-Cohen <ohad@wizery.com> writes:
>>> On Thu, Feb 21, 2013 at 8:37 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>> What do you think about creating some virtio-level wrappers for the
>>> vringh handlers?
>>>
>>> I don't think we're going to stop with caif as the only vringh user,
>>> and it could be nice if we follow the virtio spirit of decoupling the
>>> drivers from the low level implementation. It sure did prove itself
>>> when the remoteproc use cases started showing up, and it's neat.
>>
>> The problem space is a bit different. My immediate concern is getting
>> vhost (and thus vhost_net/blk) to use vringh: I wanted to unify the
>> in-userspace and in-kernelspace ring implementations. We don't have
>> that issue in virtqueue.c.
>>
>> vhost is (will be) the higher abstraction for in-userspace rings,
>> perhaps we want an equivalent for in-kernelspace rings. I'm happy to
>> look at patches, but I don't immediately see what it would look like...
>
> I'm not sure if the tight binding between vringh and remoteproc is
> a big problem. I think the most obvious use-case for kernel vringh is
> when they are instantiated from remoteproc.
>
> But if we where to make wrappers, how about something like this?
BTW, I'm leaving Ohad and you to battle it out. There's no huge hurry,
so make sure you're both happy.
> diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
> index 29b9104..ca257d8 100644
> --- a/include/linux/virtio_config.h
> +++ b/include/linux/virtio_config.h
> @@ -53,0 +54,8 @@
> + * @find_vrh: find the host vrings and instantiate them
> + * vdev: the virtio_device
> + * nhvrs: the number of host vrings to find
> + * hvrs: on success, includes new host vrings
> + * callbacks: array of driver callbacks, for each host vring
> + * include a NULL entry for vqs that do not need a callback
> + * Returns 0 on success or error status
> + * @del_vrh: free the host vrings found by find_vrh().
> @@ -55,0 +64 @@ typedef void vq_callback_t(struct virtqueue *);
> +typedef void vrh_callback_t(struct virtio_device *, struct vringh *);
> @@ -72,0 +82,4 @@ struct virtio_config_ops {
> + int (*find_vrh) (struct virtio_device *, unsigned nhvrs,
> + struct vringh *vrhs[],
> + vrh_callback_t *callbacks[]);
> + int (*del_vrhs)(struct virtio_device *);
> diff --git a/include/linux/vringh.h b/include/linux/vringh.h
> index 4c4c918..78aecc9 100644
> --- a/include/linux/vringh.h
> +++ b/include/linux/vringh.h
> @@ -52,0 +53,3 @@ struct vringh {
> +
> + /* The function to call when buffers are available */
> + void (*notify)(struct vringh *);
This will work for vhost, too, so no problems here.
Cheers,
Rusty.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2013-02-28 3:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-27 12:01 Wrappers for vringh (was Re: [PATCHv2 vringh 1/3] remoteproc: Add support for vringh (Host vrings)) Sjur Brændeland
2013-02-28 3:19 ` Rusty Russell [this message]
2013-03-03 5:54 ` Ohad Ben-Cohen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87txoxceg1.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=dmitry.tarnyagin@stericsson.com \
--cc=erwan.yvin@stericsson.com \
--cc=ido@wizery.com \
--cc=linus.walleij@linaro.org \
--cc=ohad@wizery.com \
--cc=sjurbren@gmail.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.