From: "Alex Bennée" <alex.bennee@linaro.org>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Fran??ois Ozog <francois.ozog@linaro.org>,
Stefano Stabellini <sstabellini@kernel.org>,
paul@xen.org,
Stratos Mailing List <stratos-dev@op-lists.linaro.org>,
virtio-dev@lists.oasis-open.org,
Jan Kiszka <jan.kiszka@siemens.com>,
Arnd Bergmann <arnd.bergmann@linaro.org>,
jgross@suse.com, julien@xen.org,
Carl van Schaik <cvanscha@qti.qualcomm.com>,
Bertrand.Marquis@arm.com, stefanha@redhat.com,
Artem_Mygaiev@epam.com, xen-devel@lists.xen.org,
olekstysh@gmail.com, Oleksandr_Tyshchenko@epam.com,
xen-devel@lists.xenproject.org
Subject: [virtio-dev] Re: [Stratos-dev] Enabling hypervisor agnosticism for VirtIO backends
Date: Wed, 01 Sep 2021 09:57:45 +0100 [thread overview]
Message-ID: <87eea8hdsh.fsf@linaro.org> (raw)
In-Reply-To: <20210813051038.GA77540@laputa>
AKASHI Takahiro <takahiro.akashi@linaro.org> writes:
> Hi François,
>
> On Thu, Aug 12, 2021 at 09:55:52AM +0200, Fran??ois Ozog wrote:
>> I top post as I find it difficult to identify where to make the comments.
>
> Thank you for the posting.
> I think that we should first discuss more about the goal/requirements/
> practical use cases for the framework.
>
>> 1) BE acceleration
>> Network and storage backends may actually be executed in SmartNICs. As
>> virtio 1.1 is hardware friendly, there may be SmartNICs with virtio 1.1 PCI
>> VFs. Is it a valid use case for the generic BE framework to be used in this
>> context?
>> DPDK is used in some BE to significantly accelerate switching. DPDK is also
>> used sometimes in guests. In that case, there are no event injection but
>> just high performance memory scheme. Is this considered as a use case?
>
> I'm not quite familiar with DPDK but it seems to be heavily reliant
> on not only virtqueues but also kvm/linux features/functionality, say,
> according to [1].
> I'm afraid that DPDK is not suitable for primary (at least, initial)
> target use.
> # In my proposal, virtio-proxy, I have in mind the assumption that we would
> # create BE VM as a baremetal application on RTOS (and/or unikernel.)
>
> But as far as virtqueue is concerned, I think we can discuss in general
> technical details as Alex suggested, including:
> - sharing or mapping memory regions for data payload
> - efficient notification mechanism
>
> [1] https://www.redhat.com/en/blog/journey-vhost-users-realm
>
>> 2) Virtio as OS HAL
>> Panasonic CTO has been calling for a virtio based HAL and based on the
>> teachings of Google GKI, an internal HAL seem inevitable in the long term.
>> Virtio is then a contender to Google promoted Android HAL. Could the
>> framework be used in that context?
>
> In this case, where will the implementation of "HAL" reside?
> I don't think the portability of "HAL" code (as a set of virtio BEs)
> is a requirement here.
When I hear people referring to VirtIO HALs I'm thinking mainly of
VirtIO FE's living in a Linux kernel. There are certainly more devices
that can get added but the commonality on the guest side I think is
pretty much a solved problem (modulo Linux-ism's creeping into the
virtio spec).
--
Alex Bennée
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Fran??ois Ozog <francois.ozog@linaro.org>,
Stefano Stabellini <sstabellini@kernel.org>,
paul@xen.org,
Stratos Mailing List <stratos-dev@op-lists.linaro.org>,
virtio-dev@lists.oasis-open.org,
Jan Kiszka <jan.kiszka@siemens.com>,
Arnd Bergmann <arnd.bergmann@linaro.org>,
jgross@suse.com, julien@xen.org,
Carl van Schaik <cvanscha@qti.qualcomm.com>,
Bertrand.Marquis@arm.com, stefanha@redhat.com,
Artem_Mygaiev@epam.com, xen-devel@lists.xen.org,
olekstysh@gmail.com, Oleksandr_Tyshchenko@epam.com,
xen-devel@lists.xenproject.org
Subject: Re: [Stratos-dev] Enabling hypervisor agnosticism for VirtIO backends
Date: Wed, 01 Sep 2021 09:57:45 +0100 [thread overview]
Message-ID: <87eea8hdsh.fsf@linaro.org> (raw)
In-Reply-To: <20210813051038.GA77540@laputa>
AKASHI Takahiro <takahiro.akashi@linaro.org> writes:
> Hi François,
>
> On Thu, Aug 12, 2021 at 09:55:52AM +0200, Fran??ois Ozog wrote:
>> I top post as I find it difficult to identify where to make the comments.
>
> Thank you for the posting.
> I think that we should first discuss more about the goal/requirements/
> practical use cases for the framework.
>
>> 1) BE acceleration
>> Network and storage backends may actually be executed in SmartNICs. As
>> virtio 1.1 is hardware friendly, there may be SmartNICs with virtio 1.1 PCI
>> VFs. Is it a valid use case for the generic BE framework to be used in this
>> context?
>> DPDK is used in some BE to significantly accelerate switching. DPDK is also
>> used sometimes in guests. In that case, there are no event injection but
>> just high performance memory scheme. Is this considered as a use case?
>
> I'm not quite familiar with DPDK but it seems to be heavily reliant
> on not only virtqueues but also kvm/linux features/functionality, say,
> according to [1].
> I'm afraid that DPDK is not suitable for primary (at least, initial)
> target use.
> # In my proposal, virtio-proxy, I have in mind the assumption that we would
> # create BE VM as a baremetal application on RTOS (and/or unikernel.)
>
> But as far as virtqueue is concerned, I think we can discuss in general
> technical details as Alex suggested, including:
> - sharing or mapping memory regions for data payload
> - efficient notification mechanism
>
> [1] https://www.redhat.com/en/blog/journey-vhost-users-realm
>
>> 2) Virtio as OS HAL
>> Panasonic CTO has been calling for a virtio based HAL and based on the
>> teachings of Google GKI, an internal HAL seem inevitable in the long term.
>> Virtio is then a contender to Google promoted Android HAL. Could the
>> framework be used in that context?
>
> In this case, where will the implementation of "HAL" reside?
> I don't think the portability of "HAL" code (as a set of virtio BEs)
> is a requirement here.
When I hear people referring to VirtIO HALs I'm thinking mainly of
VirtIO FE's living in a Linux kernel. There are certainly more devices
that can get added but the commonality on the guest side I think is
pretty much a solved problem (modulo Linux-ism's creeping into the
virtio spec).
--
Alex Bennée
next prev parent reply other threads:[~2021-09-01 8:59 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-04 9:04 [virtio-dev] Enabling hypervisor agnosticism for VirtIO backends Alex Bennée
2021-08-04 19:20 ` Stefano Stabellini
2021-08-11 6:27 ` AKASHI Takahiro
2021-08-14 15:37 ` Oleksandr Tyshchenko
2021-08-16 10:04 ` Wei Chen
2021-08-17 8:07 ` AKASHI Takahiro
2021-08-17 8:39 ` Wei Chen
2021-08-18 5:38 ` AKASHI Takahiro
2021-08-18 8:35 ` Wei Chen
2021-08-20 6:41 ` AKASHI Takahiro
2021-08-26 9:40 ` AKASHI Takahiro
2021-08-26 12:10 ` Wei Chen
2021-08-30 19:36 ` Christopher Clark
2021-08-30 19:53 ` [virtio-dev] " Christopher Clark
2021-08-30 19:53 ` Christopher Clark
2021-09-02 7:19 ` AKASHI Takahiro
2021-09-07 0:57 ` [virtio-dev] " Christopher Clark
2021-09-07 0:57 ` Christopher Clark
2021-09-07 11:55 ` AKASHI Takahiro
2021-09-07 18:09 ` [virtio-dev] " Christopher Clark
2021-09-07 18:09 ` Christopher Clark
2021-09-10 3:12 ` AKASHI Takahiro
2021-08-31 6:18 ` AKASHI Takahiro
2021-09-01 11:12 ` Wei Chen
2021-09-01 12:29 ` AKASHI Takahiro
2021-09-01 16:26 ` Oleksandr Tyshchenko
2021-09-02 1:30 ` Wei Chen
2021-09-02 1:50 ` Wei Chen
[not found] ` <0100017b33e585a5-06d4248e-b1a7-485e-800c-7ead89e5f916-000000@email.amazonses.com>
2021-08-12 7:55 ` [Stratos-dev] " François Ozog
2021-08-13 5:10 ` AKASHI Takahiro
2021-09-01 8:57 ` Alex Bennée [this message]
2021-09-01 8:57 ` Alex Bennée
2021-08-17 10:41 ` [virtio-dev] " Stefan Hajnoczi
2021-08-17 10:41 ` Stefan Hajnoczi
2021-08-23 6:25 ` AKASHI Takahiro
2021-08-23 9:58 ` [virtio-dev] " Stefan Hajnoczi
2021-08-23 9:58 ` Stefan Hajnoczi
2021-08-25 10:29 ` AKASHI Takahiro
2021-08-25 15:02 ` [virtio-dev] " Stefan Hajnoczi
2021-08-25 15:02 ` Stefan Hajnoczi
2021-09-01 12:53 ` [virtio-dev] " Alex Bennée
2021-09-01 12:53 ` Alex Bennée
2021-09-02 9:12 ` [virtio-dev] " Stefan Hajnoczi
2021-09-02 9:12 ` Stefan Hajnoczi
2021-09-03 8:06 ` AKASHI Takahiro
2021-09-03 9:28 ` [virtio-dev] " Alex Bennée
2021-09-03 9:28 ` Alex Bennée
2021-09-06 2:23 ` AKASHI Takahiro
2021-09-07 2:41 ` [virtio-dev] Re: [Stratos-dev] " Christopher Clark
2021-09-07 2:41 ` Christopher Clark
2021-09-10 2:50 ` AKASHI Takahiro
2021-09-10 9:35 ` [virtio-dev] " Alex Bennée
2021-09-10 9:35 ` Alex Bennée
2021-09-13 23:51 ` Stefano Stabellini
2021-09-14 6:08 ` [Stratos-dev] " François Ozog
2021-09-14 14:25 ` [virtio-dev] " Alex Bennée
2021-09-14 14:25 ` Alex Bennée
2021-09-14 17:38 ` [Stratos-dev] " Trilok Soni
2021-09-15 3:29 ` Stefano Stabellini
2021-09-15 23:50 ` Trilok Soni
2021-09-16 2:11 ` Stefano Stabellini
2021-08-05 15:48 ` [virtio-dev] " Stefan Hajnoczi
2021-08-19 9:11 ` [virtio-dev] " Matias Ezequiel Vara Larsen
[not found] ` <20210820060558.GB13452@laputa>
2021-08-21 14:08 ` Matias Ezequiel Vara Larsen
[not found] ` <20210823012029.GB40863@laputa>
2021-10-04 11:33 ` Matias Ezequiel Vara Larsen
2021-09-01 8:43 ` Alex Bennée
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=87eea8hdsh.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Artem_Mygaiev@epam.com \
--cc=Bertrand.Marquis@arm.com \
--cc=Oleksandr_Tyshchenko@epam.com \
--cc=arnd.bergmann@linaro.org \
--cc=cvanscha@qti.qualcomm.com \
--cc=francois.ozog@linaro.org \
--cc=jan.kiszka@siemens.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=olekstysh@gmail.com \
--cc=paul@xen.org \
--cc=sstabellini@kernel.org \
--cc=stefanha@redhat.com \
--cc=stratos-dev@op-lists.linaro.org \
--cc=takahiro.akashi@linaro.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xen-devel@lists.xen.org \
--cc=xen-devel@lists.xenproject.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.