qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 32/50] multi-process: Use separate MMIO communication chan


From: Jag Raman
Subject: Re: [PATCH v5 32/50] multi-process: Use separate MMIO communication channel
Date: Tue, 10 Mar 2020 14:04:23 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0



On 3/6/2020 11:52 AM, Stefan Hajnoczi wrote:
This went unanswered in the last revision:

On Thu, Nov 21, 2019 at 12:31:42PM +0000, Stefan Hajnoczi wrote:
On Wed, Nov 13, 2019 at 11:14:50AM -0500, Jag Raman wrote:
On 11/11/2019 11:21 AM, Stefan Hajnoczi wrote:
On Thu, Oct 24, 2019 at 05:09:13AM -0400, Jagannathan Raman wrote:
Using a separate communication channel for MMIO helps
with improving Performance

Why?

Typical initiation of IO operations involves multiple MMIO accesses per
IO operation. In some legacy devices like LSI, the completion of the IO
operations is also accomplished by polling on MMIO registers. Therefore,
MMIO traffic can be hefty in some cases and contribute to Performance.

Having a dedicated channel for MMIO ensures that it doesn't have to
compete with other messages to the remote process, especially when there
are multiple devices emulated by a single remote process.

A vCPU doing a polling read on an MMIO register will cause a BAR_READ
message to be sent to the remote process.  The vCPU thread waits for the
response to this message.

When there are multiple remote devices each has its own socket, so
communication with different remote processes does not interfere.

The only scenarios I can think of are:
1. Interference within a single device between vCPUs and/or the QEMU
    monitor.
2. A single process serving multiple devices that is implemented in a
    way such that different devices interfere with each other.

It sounds like you are saying the problem is #2, but this is still
unclear to me.  If the remote process can be implemented in a way such
that there is no interference when each device has a special MMIO
socket, then why can't it be implemented in a way such that there is no
interference when each device's main socket is used (each device has
it's own!).

Maybe I've missed the point.  It would be good if you could explain in
more detail.

Hi Stefan,

Sorry we missed this comment. We originally added this to enable
separate MMIO channels for each device in the remote process.

Given we are going to add a separate channel for each device in the
remote process based on the recent discussions, we could remove the
separate channel for MMIO.

Thank you very much!
--
Jag


Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]