ODP TO HMM COVER LETTER

Signed-off-by: Jérôme Glisse <jglisse@redhat.com>

1 files changed, 43 insertions, 22 deletions

diff --git a/cover-letter b/cover-letter
index fe6ac7a5cbf7..0b8bd60b970a 100644
--- a/cover-letter
+++ b/cover-letter
@@ -1,27 +1,48 @@
-This patchset improves the HMM driver API and add support for hugetlbfs
-and DAX mirroring. The improvement motivation was to make the ODP to HMM
-conversion easier [1]. Because we have nouveau bits schedule for 5.1 and
-to avoid any multi-tree synchronization this patchset adds few lines of
-inline function that wrap the existing HMM driver API to the improved
-API. The nouveau driver was tested before and after this patchset and it
-builds and works on both case so there is no merging issue [2].
-
-If this get merge in 5.1 the plans is to merge the HMM to ODP in 5.2 or
-5.3 if testing shows any issues (so far no issues has been found with
-limited testing but Mellanox will running heavier testing for longer
-time).
-
-To avoid spamming mm i would like to not cc mm on ODP or nouveau patches,
-however if people prefer to see those on mm mailing list then i can keep
-it cced.
+This patchset convert RDMA ODP to use HMM underneath this is motivated
+by stronger code sharing for same feature (share virtual memory SVM or
+Share Virtual Address SVA) and also stronger integration with mm code to
+achieve that. It depends on HMM patchset posted for inclusion in 5.1 so
+earliest target for this should be 5.2. I welcome any testing people can
+do on this.
+
+Moreover they are some features of HMM in the works like peer to peer
+support, fast CPU page table snapshot, fast IOMMU mapping update ...
+It will be easier for RDMA devices with ODP to leverage those if they
+use HMM underneath.
+
+Quick summary of what HMM is:
+    HMM is a toolbox for device driver to implement software support for
+    Share Virtual Memory (SVM). Not only it provides helpers to mirror a
+    process address space on a device (hmm_mirror). It also provides
+    helper to allow to use device memory to back regular valid virtual
+    address of a process (any valid mmap that is not an mmap of a device
+    or a DAX mapping). They are two kinds of device memory. Private memory
+    that is not accessible to CPU because it does not have all the expected
+    properties (this is for all PCIE devices) or public memory which can
+    also be access by CPU without restriction (with OpenCAPI or CCIX or
+    similar cache-coherent and atomic inter-connect).
+
+    Device driver can use each of HMM tools separatly. You do not have to
+    use all the tools it provides.
+
+For RDMA device i do not expect a need to use the device memory support
+of HMM. This device memory support is geared toward accelerator like GPU.
+
+
+You can find a branch [1] with all the prerequisite in. This patch is on
+top of 5.0rc2+ but i can rebase it on any specific branch before it is
+consider for inclusion (5.2 at best).
+
+Questions and reviews are more than welcome.
 
 [1] https://cgit.freedesktop.org/~glisse/linux/log/?h=odp-hmm
 [2] https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-for-5.1
 
-Cc: Andrew Morton <akpm@linux-foundation.org>
-Cc: Felix Kuehling <Felix.Kuehling@amd.com>
-Cc: Christian König <christian.koenig@amd.com>
-Cc: Ralph Campbell <rcampbell@nvidia.com>
-Cc: John Hubbard <jhubbard@nvidia.com>
 Cc: Jason Gunthorpe <jgg@mellanox.com>
-Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: Leon Romanovsky <leonro@mellanox.com>
+Cc: Doug Ledford <dledford@redhat.com>
+Cc: Artemy Kovalyov <artemyko@mellanox.com>
+Cc: Moni Shoua <monis@mellanox.com>
+Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Cc: Kaike Wan <kaike.wan@intel.com>
+Cc: Dennis Dalessandro <dennis.dalessandro@intel.com>