From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5515-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 00D0E985A9A for ; Sun, 24 Feb 2019 21:19:26 +0000 (UTC) MIME-Version: 1.0 References: <20190212164626.GG2715@work-vm> <20190212135924-mutt-send-email-mst@kernel.org> <20190212221738-mutt-send-email-mst@kernel.org> <20190212231458-mutt-send-email-mst@kernel.org> <20190222163900-mutt-send-email-mst@kernel.org> In-Reply-To: <20190222163900-mutt-send-email-mst@kernel.org> From: Frank Yang Date: Sun, 24 Feb 2019 13:19:13 -0800 Message-ID: Content-Type: multipart/alternative; boundary="000000000000cfeca10582aa6054" Subject: Re: [virtio-dev] Memory sharing device To: "Michael S. Tsirkin" Cc: "Dr. David Alan Gilbert" , Cornelia Huck , Roman Kiryanov , Gerd Hoffmann , Stefan Hajnoczi , virtio-dev@lists.oasis-open.org, Greg Hartman List-ID: --000000000000cfeca10582aa6054 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 22, 2019 at 2:05 PM Michael S. Tsirkin wrote: > On Wed, Feb 13, 2019 at 11:15:12PM -0800, Frank Yang wrote: > > Revised the spec to clean up a straggling mention of callbacks, and > added a > > concrete example of how it would be used for a video codec. > > > > Inlined here: > > BTW I'd rather you started sending versioned RFC patches. > This thread's too large already. > > > Ok, I've started a new thread on virtio-comment that re-shuffles the github links I've sent over so far, and responds to your latest questions. Thanks Michael! > > \subsection{Example Use Case}\label{sec:Device Types / Host Memory > Device / > > Example Use Case} > > > > Suppose the guest wants to decode a compressed video buffer. > > > > \begin{enumerate} > > > > \item Guest creates an instance for the codec vendor id / device id / > revision. > > OK we'll need to see how do we come up with a way to avoid conflicts > here, e.g. if multiple vendors will use this device. > > > \item Guest allocates into the PCI region via config virtqueue messages. > > OK so who allocates memory out of the PCI region? > Is it the host or the guest? > E.g. does guest say "I want X bytes" and host would respond > "here they are, start at offset X"? > > > \item Guest sends a message over the ping virtqueue for the host to back > that > > memory. > > And all of these will need to be maintained on the host right? > How many of these regions need to be supported? > > > > > \item Host codec device implementation exposes codec library's buffer > directly > > to guest. > > > > \item Guest: now that the memory is host backed, the guest mmap()'s and > > downloads the compressed video stream directly to the host buffer. > > > > \item Guest: After a packet of compressed video stream is downloaded to > the > > buffer, another message, like a doorbell, is sent on the ping > virtqueue to > > consume existing compressed data. The ping message's offset > field is > > set to the proper offset into the shared-mem object. > > BTW is this terminology e.g. "download", "ping message" standard somewhere? > > > \item Host: The ping message arrives on the host and the offset is > resolved to > > a physical address and then, if possible, the physical address to a > host > > pointer. Since the memory is now backed, the host pointer is also > > resolved. > > > > \item Host: Codec implementation decodes the video and puts the decoded > frames > > to either a host-side display library (thus with no further guest > > communication necessary), or puts the raw decompressed frame to a > > further offset in the host buffer that the guest knows about. > > > > \item Guest: Continue downloading video streams and hitting the > doorbell, or > > optionally, wait until the host is done first. If scheduling is not > that > > big of an impact, this can be done without even any further VM > exit, by > > the host writing to an agreed memory location when decoding is > done, > > then the guest uses a polling sleep(N) where N is the correctly > tuned > > timeout such that only a few poll spins are necessary. > > > > > > \item Guest: Or, the host can send back on the event virtqueue > \field{revents} > > and the guest can perform a blocking read() for it. > > > > \end{enumerate} > > > > The unique / interesting aspects of virtio-hostmem are demonstrated: > > > > \begin{enumerate} > > > > \item During instance creation the host was allowed to reject the > request if > > the codec device did not exist on host. > > > > \item The host can expose a codec library buffer directly to the guest, > > allowing the guest to write into it with zero copy and the host to > decompress > > again without copying. > > > > \item Large bidirectional transfers are possible with zero copy. > > However just to make sure, sending small amounts of data > is slower since you get to do all the mmap dance. > > > > \item Large bidirectional transfers are possible without scatterlists, > because > > the memory is always physically contiguous. > > It might get fragmented though. I think it would be up to > host to try and make sure it's not too fragmented, right? > > > > \item It is not necessary to use socket datagrams or data streams to > > communicate the ping messages; they can be raw structs fresh off the > > virtqueue. > > OK and ping messages are all fixed size? > > > > \item After decoding, the guest has the option but not the requirement > to wait > > for the host round trip, allowing for async operation of the codec. > > > > \item The guest has the option but not the requirement to wait for the > host > > round trip, allowing for async operation of the codec. > > > > \end{enumerate} > > OK I still owe you that write-up about vhost pci. will try to complete > that early next week. But generally if I got it right that the host > allocates buffers then what you describe does seem to fit a bit better > with the vhost pci host/guest interface idea. > > One question that was asked about vhost pci is whether it is in fact > necessary to share a device between multiple applications. > Or is it enough to just have one id per device? > > Thanks! > -- > MST > --000000000000cfeca10582aa6054 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 22, 2019 at 2:05 PM Micha= el S. Tsirkin <mst@redhat.com> = wrote:
On Wed, F= eb 13, 2019 at 11:15:12PM -0800, Frank Yang wrote:
> Revised the spec to clean up a straggling mention of callbacks, and ad= ded a
> concrete example of how it would be used for a video codec.
>
> Inlined here:

BTW I'd rather you started sending versioned RFC patches.
This thread's too large already.


Ok, I've started a new thread on virtio-comment t= hat re-shuffles the github links I've sent over so far, and responds to= your latest questions. Thanks Michael!
=C2=A0
> \subsection{Example Use Case}\label{sec:Device Types / Host Memory Dev= ice /
> Example Use Case}
>
> Suppose the guest wants to decode a compressed video buffer.
>
> \begin{enumerate}
>
> \item Guest creates an instance for the codec vendor id / device id / = revision.

OK we'll need to see how do we come up with a way to avoid conflicts here, e.g. if multiple vendors will use this device.

> \item Guest allocates into the PCI region via config virtqueue message= s.

OK so who allocates memory out of the PCI region?
Is it the host or the guest?
E.g. does guest say "I want X bytes" and host would respond
"here they are, start at offset X"?

> \item Guest sends a message over the ping virtqueue for the host to ba= ck that
> memory.

And all of these will need to be maintained on the host right?
How many of these regions need to be supported?

>
> \item Host codec device implementation exposes codec library's buf= fer directly
> to guest.
>
> \item Guest: now that the memory is host backed, the guest mmap()'= s and
> =C2=A0 =C2=A0 downloads the compressed video stream directly to the ho= st buffer.
>
> \item Guest: After a packet of compressed video stream is downloaded t= o the
> =C2=A0 =C2=A0 buffer, another message, like a doorbell, is sent on the= ping virtqueue to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 consume existing compressed data. The ping= message's offset field is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 set to the proper offset into the shared-m= em object.

BTW is this terminology e.g. "download", "ping message"= standard somewhere?

> \item Host: The ping message arrives on the host and the offset is res= olved to
> =C2=A0 =C2=A0 a physical address and then, if possible, the physical a= ddress to a host
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 pointer. Since the memory is now backed, t= he host pointer is also
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 resolved.
>
> \item Host: Codec implementation decodes the video and puts the decode= d frames
> =C2=A0 =C2=A0 to either a host-side display library (thus with no furt= her guest
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 communication necessary), or puts the raw = decompressed frame to a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 further offset in the host buffer that the= guest knows about.
>
> \item Guest: Continue downloading video streams and hitting the doorbe= ll, or
> =C2=A0 =C2=A0 optionally, wait until the host is done first. If schedu= ling is not that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 big of an impact, this can be done without= even any further VM exit, by
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the host writing to an agreed memory locat= ion when decoding is done,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 then the guest uses a polling sleep(N) whe= re N is the correctly tuned
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 timeout such that only a few poll spins ar= e necessary.
>
>
> \item Guest: Or, the host can send back on the event virtqueue \field{= revents}
> =C2=A0 =C2=A0 and the guest can perform a blocking read() for it.
>
> \end{enumerate}
>
> The unique / interesting aspects of virtio-hostmem are demonstrated: >
> \begin{enumerate}
>
> \item During instance creation the host was allowed to reject the requ= est if
> =C2=A0 =C2=A0 the codec device did not exist on host.
>
> \item The host can expose a codec library buffer directly to the guest= ,
> allowing the guest to write into it with zero copy and the host to dec= ompress
> again without copying.
>
> \item Large bidirectional transfers are possible with zero copy.

However just to make sure, sending small amounts of data
is slower since you get to do all the mmap dance.


> \item Large bidirectional transfers are possible without scatterlists,= because
> =C2=A0 =C2=A0 the memory is always physically contiguous.

It might get fragmented though. I think it would be up to
host to try and make sure it's not too fragmented, right?


> \item It is not necessary to use socket datagrams or data streams to > =C2=A0 =C2=A0 communicate the ping messages; they can be raw structs f= resh off the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 virtqueue.

OK and ping messages are all fixed size?


> \item After decoding, the guest has the option but not the requirement= to wait
> =C2=A0 =C2=A0 for the host round trip, allowing for async operation of= the codec.
>
> \item The guest has the option but not the requirement to wait for the= host
> =C2=A0 =C2=A0 round trip, allowing for async operation of the codec. >
> \end{enumerate}

OK I still owe you that write-up about vhost pci.=C2=A0 will try to complet= e
that early next week. But generally if I got it right that the host
allocates buffers then what you describe does seem to fit a bit better
with the vhost pci host/guest interface idea.

One question that was asked about vhost pci is whether it is in fact
necessary to share a device between multiple applications.
Or is it enough to just have one id per device?

Thanks!
--
MST
--000000000000cfeca10582aa6054--