import 15.2.0 Octopus source

[ceph.git] / ceph / src / spdk / doc / memory.md

diff --git a/ceph/src/spdk/doc/memory.md b/ceph/src/spdk/doc/memory.md
index abe81ffaf71b7d3701240754ecaed530ef67b564..f18af4717d62112562bcd4b7e480db01943e1569 100644 (file)
--- a/ceph/src/spdk/doc/memory.md
+++ b/ceph/src/spdk/doc/memory.md
@@ -1,4 +1,4 @@
-# Memory Management for User Space Drivers {#memory}
+# Direct Memory Access (DMA) From User Space {#memory}
 
 The following is an attempt to explain why all data buffers passed to SPDK must
 be allocated using spdk_dma_malloc() or its siblings, and why SPDK relies on
@@ -85,10 +85,7 @@ allocating `hugepages` (by default, 2MiB). The Linux kernel treats hugepages
 differently than regular 4KiB pages. Specifically, the operating system will
 never change their physical location. This is not by intent, and so things
 could change in future versions, but it is true today and has been for a number
-of years (see the later section on the IOMMU for a future-proof solution). DPDK
-goes through great pains to allocate hugepages such that it can string together
-the longest runs of physical pages possible, such that it can accommodate
-physically contiguous allocations larger than a single page.
+of years (see the later section on the IOMMU for a future-proof solution).
 
 With this explanation, hopefully it is now clear why all data buffers passed to
 SPDK must be allocated using spdk_dma_malloc() or its siblings. The buffers