From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Pincus, Josh" <Josh.Pincus@windriver.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"zhabin@linux.alibaba.com" <zhabin@linux.alibaba.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
qemu-devel@nongnu.org
Subject: [virtio-dev] Re: [PATCH v2 0/5] virtio mmio specification enhancement
Date: Mon, 03 Aug 2020 17:19:56 +0100 [thread overview]
Message-ID: <87wo2fn1lf.fsf@linaro.org> (raw)
In-Reply-To: <87ft973d0b.fsf@linaro.org>
Alex Bennée <alex.bennee@linaro.org> writes:
> Pincus, Josh <Josh.Pincus@windriver.com> writes:
>
>> Hi,
>>
>>
>>
>> We were looking into a similar enhancement for the Virt I/O MMIO transport and came across this project.
>>
>> This enhancement would be perfect for us.
>
> So there is certainly an interest in optimising MMIO based virtio and
> the current read/ack cycle adds additional round trip time for any trap
> and emulate hypervisor. However I think there is some resistance to
> making MMIO a re-implementation of what PCI already gives us for "free".
<snip>
>
> - Quantifying the memory foot-print difference between PCI/MMIO
>
> PCI gives a lot for free including a discovery and IRQ model already
> designed to handle MSI/MSI-X. There is a claim that this brings in a
> lot of bloat but I think there was some debate around the numbers.
> My rough initial experiment with a PCI and non-PCI build with
> otherwise identical VIRTIO configs results in the following:
>
> 16:40:15 c.282% [alex@zen:~/l/l/builds] review/rpmb|… + ls -l arm64/vmlinux arm64.nopci/vmlinux
> -rwxr-xr-x 1 alex alex 83914728 Jul 31 16:39 arm64.nopci/vmlinux*
> -rwxr-xr-x 1 alex alex 86368080 Jul 31 16:33 arm64/vmlinux*
>
> which certainly implies there could be a fair amount of headroom for
> an MMIO version to implement some features. However I don't know if
> it's fully apples to apples as there maybe unneeded PCI bloat that a
> virtio-only kernel doesn't need.
Just following up after cutting the Xgene and ThunderX PCI bloat from
the kernel the margin is a little smaller:
-rwxr-xr-x 1 alex alex 83914728 Jul 31 16:39 arm64.nopci/vmlinux*
-rwxr-xr-x 1 alex alex 85639808 Aug 3 17:12 arm64/vmlinux*
--
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: "Pincus, Josh" <Josh.Pincus@windriver.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"zhabin@linux.alibaba.com" <zhabin@linux.alibaba.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v2 0/5] virtio mmio specification enhancement
Date: Mon, 03 Aug 2020 17:19:56 +0100 [thread overview]
Message-ID: <87wo2fn1lf.fsf@linaro.org> (raw)
In-Reply-To: <87ft973d0b.fsf@linaro.org>
Alex Bennée <alex.bennee@linaro.org> writes:
> Pincus, Josh <Josh.Pincus@windriver.com> writes:
>
>> Hi,
>>
>>
>>
>> We were looking into a similar enhancement for the Virt I/O MMIO transport and came across this project.
>>
>> This enhancement would be perfect for us.
>
> So there is certainly an interest in optimising MMIO based virtio and
> the current read/ack cycle adds additional round trip time for any trap
> and emulate hypervisor. However I think there is some resistance to
> making MMIO a re-implementation of what PCI already gives us for "free".
<snip>
>
> - Quantifying the memory foot-print difference between PCI/MMIO
>
> PCI gives a lot for free including a discovery and IRQ model already
> designed to handle MSI/MSI-X. There is a claim that this brings in a
> lot of bloat but I think there was some debate around the numbers.
> My rough initial experiment with a PCI and non-PCI build with
> otherwise identical VIRTIO configs results in the following:
>
> 16:40:15 c.282% [alex@zen:~/l/l/builds] review/rpmb|… + ls -l arm64/vmlinux arm64.nopci/vmlinux
> -rwxr-xr-x 1 alex alex 83914728 Jul 31 16:39 arm64.nopci/vmlinux*
> -rwxr-xr-x 1 alex alex 86368080 Jul 31 16:33 arm64/vmlinux*
>
> which certainly implies there could be a fair amount of headroom for
> an MMIO version to implement some features. However I don't know if
> it's fully apples to apples as there maybe unneeded PCI bloat that a
> virtio-only kernel doesn't need.
Just following up after cutting the Xgene and ThunderX PCI bloat from
the kernel the margin is a little smaller:
-rwxr-xr-x 1 alex alex 83914728 Jul 31 16:39 arm64.nopci/vmlinux*
-rwxr-xr-x 1 alex alex 85639808 Aug 3 17:12 arm64/vmlinux*
--
Alex Bennée
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Pincus, Josh" <Josh.Pincus@windriver.com>
Cc: "virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"zhabin@linux.alibaba.com" <zhabin@linux.alibaba.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v2 0/5] virtio mmio specification enhancement
Date: Mon, 03 Aug 2020 17:19:56 +0100 [thread overview]
Message-ID: <87wo2fn1lf.fsf@linaro.org> (raw)
In-Reply-To: <87ft973d0b.fsf@linaro.org>
Alex Bennée <alex.bennee@linaro.org> writes:
> Pincus, Josh <Josh.Pincus@windriver.com> writes:
>
>> Hi,
>>
>>
>>
>> We were looking into a similar enhancement for the Virt I/O MMIO transport and came across this project.
>>
>> This enhancement would be perfect for us.
>
> So there is certainly an interest in optimising MMIO based virtio and
> the current read/ack cycle adds additional round trip time for any trap
> and emulate hypervisor. However I think there is some resistance to
> making MMIO a re-implementation of what PCI already gives us for "free".
<snip>
>
> - Quantifying the memory foot-print difference between PCI/MMIO
>
> PCI gives a lot for free including a discovery and IRQ model already
> designed to handle MSI/MSI-X. There is a claim that this brings in a
> lot of bloat but I think there was some debate around the numbers.
> My rough initial experiment with a PCI and non-PCI build with
> otherwise identical VIRTIO configs results in the following:
>
> 16:40:15 c.282% [alex@zen:~/l/l/builds] review/rpmb|… + ls -l arm64/vmlinux arm64.nopci/vmlinux
> -rwxr-xr-x 1 alex alex 83914728 Jul 31 16:39 arm64.nopci/vmlinux*
> -rwxr-xr-x 1 alex alex 86368080 Jul 31 16:33 arm64/vmlinux*
>
> which certainly implies there could be a fair amount of headroom for
> an MMIO version to implement some features. However I don't know if
> it's fully apples to apples as there maybe unneeded PCI bloat that a
> virtio-only kernel doesn't need.
Just following up after cutting the Xgene and ThunderX PCI bloat from
the kernel the margin is a little smaller:
-rwxr-xr-x 1 alex alex 83914728 Jul 31 16:39 arm64.nopci/vmlinux*
-rwxr-xr-x 1 alex alex 85639808 Aug 3 17:12 arm64/vmlinux*
--
Alex Bennée
next prev parent reply other threads:[~2020-08-03 16:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-30 20:15 [PATCH v2 0/5] virtio mmio specification enhancement Pincus, Josh
2020-07-31 10:13 ` Stefan Hajnoczi
2020-07-31 10:13 ` Stefan Hajnoczi
2020-07-31 15:44 ` [virtio-dev] " Alex Bennée
2020-07-31 15:44 ` Alex Bennée
2020-07-31 15:44 ` Alex Bennée
2020-08-03 16:19 ` Alex Bennée [this message]
2020-08-03 16:19 ` Alex Bennée
2020-08-03 16:19 ` Alex Bennée
2020-08-03 23:31 ` Pincus, Josh
2020-08-03 23:31 ` Pincus, Josh
-- strict thread matches above, loose matches on Subject: below --
2020-02-10 9:05 Zha Bin
2020-02-10 11:44 ` [virtio-dev] " Michael S. Tsirkin
2020-02-11 16:05 ` Chao Peng
2020-02-11 10:57 ` [virtio-dev] " Michael S. Tsirkin
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=87wo2fn1lf.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Josh.Pincus@windriver.com \
--cc=linux-kernel@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=zhabin@linux.alibaba.com \
/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.