From: "Roger Pau Monné" <roger.pau@citrix.com> To: Dongwon Kim <dongwon.kim@intel.com> Cc: <linux-kernel@vger.kernel.org>, <linaro-mm-sig@lists.linaro.org>, <xen-devel@lists.xenproject.org>, <sumit.semwal@linaro.org>, <dri-devel@lists.freedesktop.org>, <mateuszx.potrola@intel.com> Subject: Re: [Xen-devel] [RFC PATCH v2 2/9] hyper_dmabuf: architecture specification and reference guide Date: Fri, 23 Feb 2018 16:15:00 +0000 [thread overview] Message-ID: <20180223161500.xpbqnpsxihoxi5o4@MacBook-Pro-de-Roger.local> (raw) In-Reply-To: <20180214015008.9513-3-dongwon.kim@intel.com> On Tue, Feb 13, 2018 at 05:50:01PM -0800, Dongwon Kim wrote: > Reference document for hyper_DMABUF driver > > Documentation/hyper-dmabuf-sharing.txt This should likely be patch 1 in order for reviewers to have the appropriate context. > > Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> > --- > Documentation/hyper-dmabuf-sharing.txt | 734 +++++++++++++++++++++++++++++++++ > 1 file changed, 734 insertions(+) > create mode 100644 Documentation/hyper-dmabuf-sharing.txt > > diff --git a/Documentation/hyper-dmabuf-sharing.txt b/Documentation/hyper-dmabuf-sharing.txt > new file mode 100644 > index 000000000000..928e411931e3 > --- /dev/null > +++ b/Documentation/hyper-dmabuf-sharing.txt > @@ -0,0 +1,734 @@ > +Linux Hyper DMABUF Driver > + > +------------------------------------------------------------------------------ > +Section 1. Overview > +------------------------------------------------------------------------------ > + > +Hyper_DMABUF driver is a Linux device driver running on multiple Virtual > +achines (VMs), which expands DMA-BUF sharing capability to the VM environment > +where multiple different OS instances need to share same physical data without > +data-copy across VMs. > + > +To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the > +exporting VM (so called, “exporter”) imports a local DMA_BUF from the original > +producer of the buffer, The usage of export and import in the above sentence makes it almost impossible to understand. > then re-exports it with an unique ID, hyper_dmabuf_id > +for the buffer to the importing VM (so called, “importer”). And this is even worse. Maybe it would help to have some kind of flow diagram of all this import/export operations, but please read below. > + > +Another instance of the Hyper_DMABUF driver on importer registers > +a hyper_dmabuf_id together with reference information for the shared physical > +pages associated with the DMA_BUF to its database when the export happens. > + > +The actual mapping of the DMA_BUF on the importer’s side is done by > +the Hyper_DMABUF driver when user space issues the IOCTL command to access > +the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and > +exporting driver as is, that is, no special configuration is required. > +Consequently, only a single module per VM is needed to enable cross-VM DMA_BUF > +exchange. IMHO I need a more generic view of the problem you are trying to solve in the overview section. I've read the full overview, and I still have no idea why you need all this. I think the overview should contain at least: 1. A description of the problem you are trying to solve. 2. A high level description of the proposed solution. 3. How the proposed solution deals with the problem described in 1. This overview is not useful for people that don't know which problem you are trying to solve, like myself. Thanks, Roger.
WARNING: multiple messages have this Message-ID (diff)
From: "Roger Pau Monné" <roger.pau@citrix.com> To: Dongwon Kim <dongwon.kim@intel.com> Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, mateuszx.potrola@intel.com, xen-devel@lists.xenproject.org, sumit.semwal@linaro.org Subject: Re: [RFC PATCH v2 2/9] hyper_dmabuf: architecture specification and reference guide Date: Fri, 23 Feb 2018 16:15:00 +0000 [thread overview] Message-ID: <20180223161500.xpbqnpsxihoxi5o4@MacBook-Pro-de-Roger.local> (raw) In-Reply-To: <20180214015008.9513-3-dongwon.kim@intel.com> On Tue, Feb 13, 2018 at 05:50:01PM -0800, Dongwon Kim wrote: > Reference document for hyper_DMABUF driver > > Documentation/hyper-dmabuf-sharing.txt This should likely be patch 1 in order for reviewers to have the appropriate context. > > Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> > --- > Documentation/hyper-dmabuf-sharing.txt | 734 +++++++++++++++++++++++++++++++++ > 1 file changed, 734 insertions(+) > create mode 100644 Documentation/hyper-dmabuf-sharing.txt > > diff --git a/Documentation/hyper-dmabuf-sharing.txt b/Documentation/hyper-dmabuf-sharing.txt > new file mode 100644 > index 000000000000..928e411931e3 > --- /dev/null > +++ b/Documentation/hyper-dmabuf-sharing.txt > @@ -0,0 +1,734 @@ > +Linux Hyper DMABUF Driver > + > +------------------------------------------------------------------------------ > +Section 1. Overview > +------------------------------------------------------------------------------ > + > +Hyper_DMABUF driver is a Linux device driver running on multiple Virtual > +achines (VMs), which expands DMA-BUF sharing capability to the VM environment > +where multiple different OS instances need to share same physical data without > +data-copy across VMs. > + > +To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the > +exporting VM (so called, “exporter”) imports a local DMA_BUF from the original > +producer of the buffer, The usage of export and import in the above sentence makes it almost impossible to understand. > then re-exports it with an unique ID, hyper_dmabuf_id > +for the buffer to the importing VM (so called, “importer”). And this is even worse. Maybe it would help to have some kind of flow diagram of all this import/export operations, but please read below. > + > +Another instance of the Hyper_DMABUF driver on importer registers > +a hyper_dmabuf_id together with reference information for the shared physical > +pages associated with the DMA_BUF to its database when the export happens. > + > +The actual mapping of the DMA_BUF on the importer’s side is done by > +the Hyper_DMABUF driver when user space issues the IOCTL command to access > +the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and > +exporting driver as is, that is, no special configuration is required. > +Consequently, only a single module per VM is needed to enable cross-VM DMA_BUF > +exchange. IMHO I need a more generic view of the problem you are trying to solve in the overview section. I've read the full overview, and I still have no idea why you need all this. I think the overview should contain at least: 1. A description of the problem you are trying to solve. 2. A high level description of the proposed solution. 3. How the proposed solution deals with the problem described in 1. This overview is not useful for people that don't know which problem you are trying to solve, like myself. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-02-23 16:16 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-14 1:49 [RFC PATCH v2 0/9] hyper_dmabuf: Hyper_DMABUF driver Dongwon Kim 2018-02-14 1:49 ` Dongwon Kim 2018-02-14 1:50 ` [RFC PATCH v2 1/9] hyper_dmabuf: initial upload of hyper_dmabuf drv core framework Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-04-10 8:53 ` [RFC, v2, " Oleksandr Andrushchenko 2018-04-10 10:47 ` [Xen-devel] " Julien Grall 2018-04-10 11:04 ` Oleksandr Andrushchenko 2018-04-10 11:04 ` Oleksandr Andrushchenko 2018-04-10 11:04 ` Oleksandr Andrushchenko 2018-04-10 10:47 ` Julien Grall 2018-04-10 8:53 ` Oleksandr Andrushchenko 2018-02-14 1:50 ` [RFC PATCH v2 " Dongwon Kim 2018-02-14 1:50 ` [RFC PATCH v2 2/9] hyper_dmabuf: architecture specification and reference guide Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-02-23 16:15 ` Roger Pau Monné [this message] 2018-02-23 16:15 ` Roger Pau Monné 2018-02-23 19:02 ` Dongwon Kim 2018-02-23 19:02 ` [Xen-devel] " Dongwon Kim 2018-02-23 19:02 ` Dongwon Kim 2018-04-10 9:52 ` [RFC, v2, " Oleksandr Andrushchenko 2018-04-10 9:52 ` Oleksandr Andrushchenko 2018-04-10 9:52 ` Oleksandr Andrushchenko 2018-02-14 1:50 ` [RFC PATCH v2 " Dongwon Kim 2018-02-14 1:50 ` [RFC PATCH v2 3/9] MAINTAINERS: adding Hyper_DMABUF driver section in MAINTAINERS Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-02-14 1:50 ` [RFC PATCH v2 4/9] hyper_dmabuf: user private data attached to hyper_DMABUF Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-04-10 9:59 ` [RFC, v2, " Oleksandr Andrushchenko 2018-04-10 9:59 ` Oleksandr Andrushchenko 2018-04-10 9:59 ` Oleksandr Andrushchenko 2018-02-14 1:50 ` [RFC PATCH v2 " Dongwon Kim 2018-02-14 1:50 ` [RFC PATCH v2 5/9] hyper_dmabuf: default backend for XEN hypervisor Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-04-10 9:27 ` [RFC, v2, " Oleksandr Andrushchenko 2018-04-10 9:27 ` [RFC,v2,5/9] " Oleksandr Andrushchenko 2018-02-14 1:50 ` [RFC PATCH v2 5/9] " Dongwon Kim 2018-02-14 1:50 ` [RFC PATCH v2 6/9] hyper_dmabuf: hyper_DMABUF synchronization across VM Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-02-14 1:50 ` [RFC PATCH v2 7/9] hyper_dmabuf: query ioctl for retreiving various hyper_DMABUF info Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-02-14 1:50 ` [RFC PATCH v2 8/9] hyper_dmabuf: event-polling mechanism for detecting a new hyper_DMABUF Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-02-14 1:50 ` [RFC PATCH v2 9/9] hyper_dmabuf: threaded interrupt in Xen-backend Dongwon Kim 2018-02-14 1:50 ` Dongwon Kim 2018-04-10 10:04 ` [RFC, v2, " Oleksandr Andrushchenko 2018-04-10 10:04 ` [RFC,v2,9/9] " Oleksandr Andrushchenko 2018-02-14 1:50 ` [RFC PATCH v2 9/9] " Dongwon Kim 2018-02-19 17:01 ` [RFC PATCH v2 0/9] hyper_dmabuf: Hyper_DMABUF driver Daniel Vetter 2018-02-19 17:01 ` Daniel Vetter 2018-02-21 20:18 ` Dongwon Kim 2018-02-21 20:18 ` Dongwon Kim 2018-02-21 20:18 ` Dongwon Kim 2018-02-19 17:01 ` Daniel Vetter
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=20180223161500.xpbqnpsxihoxi5o4@MacBook-Pro-de-Roger.local \ --to=roger.pau@citrix.com \ --cc=dongwon.kim@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mateuszx.potrola@intel.com \ --cc=sumit.semwal@linaro.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: linkBe 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.