(PR2) Adds the support for Flexible Data Placement(FDP) over NVMe into the Cachelib #277

arungeorge83 · 2023-11-15T16:34:30Z

This adds the device layer support for NVMe-FDP semantics and adds the RUH-awareness feature of NVMe-FDP in
the upper layers of Navy. This allows the BlockCache(large items) and BigHash(small items) of Navy to segregate their data streams in physical NAND media by using the FDP placement Identifiers.

With this changes, the Cachelib can reduce the Device Write Amplification (WAF) significantly even in high SSD utilization scenarios("nvmCacheSizeMB" above 50% of the SSD capacity) in most of the cachelib workloads.

This commit introduces a 'placementHandle' concept for data placement, which can be used by both BC and BH of Navy on
device write() calls, especially for FDP placements. The 'placementHandle' have to be allocated from the device.

io_uring_cmd interface(through nvme char device) is used to send FDP directives to Linux kernel, as sending it through the
conventional block interfaces is not suported yet. The user can select the NVMe block device (Namespace/partition) as usual
(Ex: "nvmCachePaths": ["/dev/nvme0n1p1"]), and the cachelib will pick the corresponding NVMe char device internally.

This commit adds a new config 'fdpMode' to enable FDP. The user needs to select the fdpMode along with iOUring I/O Engine options ("navyEnableIoUring": true, "navyQDepth": 1, "fdpMode": true).

This second PR consist of the code which can be integrated to the 'iouring async-io' support in the Navy.

jaesoo-fb

Can you check if build is OK with removing liburing package?

jaesoo-fb · 2023-11-15T23:18:15Z

cachelib/allocator/nvmcache/NavyConfig.h

@@ -541,6 +543,8 @@ class NavyConfig {
  // ============ Device settings =============
  // Set the device block size, i.e., minimum unit of IO
  void setBlockSize(uint64_t blockSize) noexcept { blockSize_ = blockSize; }
+  // Set the FDP data placment mode in device
+  void setFDPMode(bool enable) noexcept { fdp_ = enable; }


nit. setFDPEnabled

cachelib/allocator/nvmcache/NavyConfig.h

jaesoo-fb · 2023-11-15T23:44:04Z

cachelib/navy/Factory.cpp

+      if(isFDPEnabled) {
+        f = openNvmeCharFile(path);
+      } else {
+        f = openCacheFile(path, fdSize, truncateFile);
+      }


How can you support the partition? I.e., we want to use only [start_lba, start_lba + partition_size)

W.r.t. this, would it be possible to take the block device name and map it to char dev? i.e., "nvmen[p]" to "ngn"?

The rationale is that this will allow us to apply the size check and fallocate thing the same. i.e., we can do:

f = openCacheFile(path, ...); if (isFDPEnabled) { f.close(); f = openNvmeCharFile(getNvmeCharDevice(path), ...); }

Looks like there were some formatting error. I meant the mapping: "nvmeXnY[pZ]" to "ngXnY".

IIUC, your requirement is as follows,
There are partitions like nvmeXnYp1, nvmeXnYp2 ... , and one of them is used in this cachelib instance.
(Ex: nvmCachePath = "/dev/nvmeXnYp2")
OR is it just one partition in that namespace, but it happened to be partition-formatted ?

The rationale is that this will allow us to apply the size check and fallocate thing the same
Is this steps used for device simulation scenarios?

Anyway the proposed approach is doable and making sense.

cachelib/navy/bighash/BigHash.cpp

jaesoo-fb · 2023-11-16T00:11:08Z

cachelib/navy/common/Device.cpp

  auto remainingSize = size;
  auto maxWriteSize = (maxWriteSize_ == 0) ? remainingSize : maxWriteSize_;
+  maxWriteSize = (maxIOSize_ == 0) ? maxWriteSize : maxIOSize_;


remove this after fix setting maxIOSize_.

jaesoo-fb · 2023-11-16T00:15:32Z

cachelib/navy/common/Device.cpp

+#ifndef CACHELIB_IOURING_DISABLE
+  if (isFDPEnabled_) {
+    fdpNvme_ = std::make_shared<FdpNvme>(fvec_[0].fd());
+    setMaxIOSize(fdpNvme_->getMaxTfrSize());


Fix maxWriteSize_ too.

maxIOSize_ = fdpNvme_->getMaxTfrSize(); maxWriteSize_ = min(maxWriteSize_, maxIOSize_);

cachelib/navy/common/Device.cpp

jaesoo-fb · 2023-11-16T00:47:09Z

cachelib/navy/common/Device.cpp

+AsyncIoContext::prepUringCmdAsyncIo(int fd, uint8_t opType, void* data,
+    uint32_t size, uint64_t offset, void* userdata, int handle) {
+  std::unique_ptr<folly::AsyncBaseOp> asyncOp;


You might need to guard this code appropriately using CACHELIB_IOURING_DISABLE.

So, suggest to call prepUringCmdAsyncIo inside the prepAsyncIo with guarding this function with #ifndef CACHELIB_IOURING_DISABLE

jaesoo-fb · 2023-11-16T00:51:32Z

cachelib/navy/common/Device.cpp

+  } else {
+    fdpNvme_->prepWriteUringCmdSqe(sqe, fd, data, size, offset, handle);
+  }
+  asyncOp = std::move(iouringCmdOp);


Why do you need to have asyncOp separately? We can just return iouringCmdOp.

cachelib/navy/common/Device.cpp

jaesoo-fb · 2023-11-16T01:04:30Z

cachelib/navy/common/FdpNvme.cpp

+#include <linux/nvme_ioctl.h>
+#include <sys/ioctl.h>
+#include <errno.h>
+#include <cstring>
+#include <numeric>


nit. in alphabetical order?

jaesoo-fb

Can you check if this compiles in supported platforms here https://github.com/facebook/CacheLib/actions?

jaesoo-fb · 2023-11-16T01:10:26Z

cachelib/navy/common/FdpNvme.cpp

+  auto pid = getFdpPID(phndl);
+
+  return static_cast<int>(pid);


Do we need to expose the placement id here? Why not just give out the phndl?

Yes, possible.

cachelib/navy/common/FdpNvme.cpp

cachelib/navy/common/FdpNvme.h

cachelib/navy/common/FdpNvme.cpp

cachelib/navy/common/FdpNvme.h

cachelib/navy/common/FdpNvme.cpp

arungeorge83 · 2023-11-16T13:56:11Z

Can you check if build is OK with removing liburing package?

FdpNvme.cpp is not protected for this case. I guess you want to bring them under -DCACHELIB_IOURING_DISABLE, right?

arungeorge83 · 2023-11-16T14:22:33Z

Can you check if this compiles in supported platforms here https://github.com/facebook/CacheLib/actions?

As per the status,
'This workflow is awaiting approval from a maintainer in #277'
Could you check it and approve?
Or should I verify it locally?

jaesoo-fb · 2023-11-16T18:16:52Z

As per the status, 'This workflow is awaiting approval from a maintainer in #277' Could you check it and approve? Or should I verify it locally?

Oh, my bad. I just started the workflows. I expect some of them to be failed, so please fix it as it appears.

jaesoo-fb · 2023-12-01T19:04:11Z

cachelib/navy/common/Device.cpp

+    if (result) {
+      bytesRead_.add(readSize);
+    } else {
+      readIOErrors_.inc();
+      return false;
+    }


nit. return early to reduce the indent depth.

if (!result) { ... return false; } bytesRead_.add(readSize);

jaesoo-fb · 2023-12-01T19:13:08Z

cachelib/navy/common/Device.cpp

    : asyncBase_(std::move(asyncBase)),
      id_(id),
      qDepth_(capacity),
-      useIoUring_(useIoUring) {
+      useIoUring_(useIoUring),
+      fdpNvme_(fdpNvme) {
 #ifdef CACHELIB_IOURING_DISABLE
  // io_uring is not available on the system
  XDCHECK(!useIoUring_);


nit. XDCHECK(!useIoUring_ && !fdbNvme_)

you meant XDCHECK(!useIoUring_ || !fdbNvme_) ?
It is an error here, if either of them is enabled.

If CACHELIB_IOURING_DISABLE, both of useIoUring_ and fdbNvme_ should be nullptr, right?

jaesoo-fb · 2023-12-01T19:19:11Z

cachelib/navy/common/Device.cpp

+}
+#endif
+
+bool AsyncIoContext::submitIo(IOOp& op) {


nit. Could you move this back to original place, i.e., above prepAsyncIo?

jaesoo-fb · 2023-12-01T19:21:24Z

cachelib/navy/common/Device.cpp

+#ifndef CACHELIB_IOURING_DISABLE
+std::unique_ptr<folly::AsyncBaseOp> AsyncIoContext::prepNvmeIo(IOOp& op) {
+  std::unique_ptr<folly::IoUringOp> iouringCmdOp;


I think it is more simpler to guard the body to minimize the use of CACHELIB_IOURING_DISABLE, i.e.,

std::unique_ptr<folly::AsyncBaseOp> AsyncIoContext::prepNvmeIo(IOOp& op) { #ifndef CACHELIB_IOURING_DISABLE ... #else return nullptr; #endif }

jaesoo-fb · 2023-12-01T19:29:19Z

cachelib/navy/common/Device.h

+  void setMaxWriteSize(uint32_t maxWriteSize) { maxWriteSize_ = maxWriteSize; }
+
+  void setMaxIOSize(uint32_t maxIOSize) { maxIOSize_ = maxIOSize; }
+


Can we remove those after moving FdpNvme construction to createDirectIoFileDevice?

jaesoo-fb · 2023-12-01T19:31:37Z

cachelib/navy/common/Device.cpp

+    if (!!fdpNvme_) {
+      auto maxIOSize = fdpNvme_->getMaxTfrSize();
+      if (maxIOSize) {
+        setMaxIOSize(maxIOSize);
+        maxDeviceWriteSize = std::min<size_t>(maxDeviceWriteSize, maxIOSize);
+        setMaxWriteSize(maxDeviceWriteSize);
+      }
+    }


Hmm, I feel like it would be better to move this logic to createDirectIoFileDevice and pass FdpNvme and maxIOSize as parameters instead of isFDPEnabled.

Also, could you move this if inside of try without if (!!fdpNvme_)?

A query;
you meant to have something like this in the FileDevice creation, right?
FileDevice::FileDevice(...,
uint32_t maxDeviceWriteSize,
uint32_t maxIOSize,
std::shared_ptr fdpNvme,
.....)
: Device(...,
maxDeviceWriteSize,
maxIOSize)

maxIOSize would be set the Device initiation itself, right?

Yeah, something like that. Both maxIOSize_ and maxDeviceWriteSize_ would be set in the constructor initializer list.

jaesoo-fb · 2023-12-01T19:49:32Z

cachelib/navy/common/FdpNvme.cpp

+  } else {
+    throw std::bad_alloc();
+  }


Why we need this? Isn't this an assert?

Rather, I guess we need to raise some exception (invalid_argument?) if ruh_status->nruhsd is 0 to disable fdp?

if (!ruh_status->nruhsd) { throw std::invalid_argument("Failed to initialize FDP; nruhsd is 0"); }

jaesoo-fb · 2023-12-01T20:02:31Z

cachelib/navy/Factory.cpp

+  size_t devPos = blockDevice.find_first_of("0123456789");
+  size_t pPos = blockDevice.find('p', devPos);
+
+  return "/dev/ng" + blockDevice.substr(devPos, pPos - devPos);


Actually, this is not enough to support the partition; we have to set the offset and the size too. Not sure whether there is some library with which we can get the start lba and size of partition from sysfs, i.e., /sys/block/nvme1n1/nvme1n1p2/start

Right. Sorry, I missed the 'offset'.
And the 'offset' need to be passed to the createDirectIoFileDevice(), right?

Actually, I think it would be good to have all nvme specific code in Device.cpp or FdpNvme.h

A thought in the same line:
Is it ok if we keep all the nvme char device handling inside FdpNvme.cpp?

That might require two sets of folly:file.
one that is kept(file1) by FileDevice, which is of /dev/nvmeXnYpZ; the other (file2) kept by FdpNvme which is of /dev/ngXnY.
And map is kept by FdpNvme, "file1" : "file2, offset, size".
What do you say? Do you foresee any statistics collection related issues if we keep two sets of folly::file.

The other way is to have all the logic in Device.cpp:createFdpFileDevice() which in turn makes use of different functions exported through FdpNvme.h, such as openNvmeCharFile(blkdev_path) (Returns folly::file, part_offset, size etc)

Is it ok if we keep all the nvme char device handling inside FdpNvme.cpp?

Sounds good to me and prefer option 1. However, I don't think you need a map. Instead, I think we can make FdpNvme represents an FDP NVMe block device which could be a partition or a whole namespace. The char dev fd and partition offset could be property of the FdpNvme.

W.r.t. this, I can see you are initializing FdpNvme for the first device only. So, I think we can restrict FdpNvme is only supported for single block device only for now.

Okay, sure.

So, I think we can restrict FdpNvme is only supported for single block device only for now.

Yes, I am adding explicit checks and exceptions to limit the FDP support for single device for now.

facebook-github-bot · 2023-12-06T02:25:49Z

@jaesoo-fb has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

facebook-github-bot · 2023-12-06T02:34:46Z

@jaesoo-fb has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

facebook-github-bot · 2023-12-15T07:05:21Z

@arungeorge83 has updated the pull request. You must reimport the pull request before landing.

facebook-github-bot · 2023-12-15T18:52:08Z

@jaesoo-fb has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

jaesoo-fb

Overall looks good. Thanks for the work.

jaesoo-fb · 2023-12-15T18:58:02Z

cachelib/allocator/nvmcache/NavyConfig.h

@@ -549,6 +551,8 @@ class NavyConfig {
  // ============ Device settings =============
  // Set the device block size, i.e., minimum unit of IO
  void setBlockSize(uint64_t blockSize) noexcept { blockSize_ = blockSize; }
+  // Set the NVMe FDP Device data placement mode in the Cachelib
+  void setFDPMode(bool enable) noexcept { fdpEnabled_ = enable; }


nit. setEnableFDP.

Could you also change other instances of FDPMode to EnableFDP?

jaesoo-fb · 2023-12-15T18:59:47Z

cachelib/cachebench/util/CacheConfig.h

@@ -227,6 +227,9 @@ struct CacheConfig : public JSONConfig {
  // Navy will split it into multiple IOs.
  uint32_t deviceMaxWriteSize{1024 * 1024};

+  // Enable the FDP Data placement mode in the device, if it is capable.
+  bool fdpMode{false};


nit. deviceEnableFDP

jaesoo-fb · 2023-12-15T19:03:15Z

cachelib/allocator/nvmcache/NavyConfig.h

@@ -694,6 +698,9 @@ class NavyConfig {
  // Whether to use write size (instead of parcel size) for Navy admission
  // policy.
  bool useEstimatedWriteSize_{false};
+  // Whether Navy support the NVMe FDP data placement(TP4146) directives or not.
+  // Reference: https://nvmexpress.org/nvmeflexible-data-placement-fdp-blog/
+  bool fdpEnabled_{false};


nit. enableFDP_

jaesoo-fb · 2023-12-15T19:09:01Z

cachelib/navy/common/Device.cpp

+#else
+  XDCHECK(!isFDPEnabled);


nit. not needed.

jaesoo-fb · 2023-12-15T19:10:34Z

cachelib/navy/common/Device.h

+  // Some devices have this transfer size limit due to DMA size limitations.
+  // This limit is applicable for both writes and reads.
+  const uint32_t maxIOSize_{0};
+


nit. Could you move this right above maxWriteSize_ to match with the initialization order in the constructor?

jaesoo-fb · 2023-12-15T20:13:16Z

cachelib/navy/common/FdpNvme.h

+// as of now; and not supported through conventional block interfaces.
+class FdpNvme {
+ public:
+  FdpNvme(const std::string& fileName);


Make this explicit, i.e., explicit FdpNvme(...)

jaesoo-fb · 2023-12-15T20:13:37Z

cachelib/navy/common/FdpNvme.cpp

+#include <sys/ioctl.h>
+
+#include <cstring>
+#include <numeric>


Is this used?

jaesoo-fb · 2023-12-15T20:15:21Z

cachelib/navy/common/Device.cpp

@@ -788,6 +844,32 @@ bool AsyncIoContext::submitIo(IOOp& op) {
  }


I cannot add comment above. Could you remove req which is not used.

@@ -773,9 +829,8 @@ } bool AsyncIoContext::submitIo(IOOp& op) { - IOReq& req = op.parent_; - op.startTime_ = getSteadyClock(); + while (numOutstanding_ >= qDepth_) { if (qDepth_ > 1) { XLOG_EVERY_MS(ERR, 10000) << fmt::format(

jaesoo-fb · 2023-12-15T20:17:47Z

cachelib/navy/testing/MockDevice.h

@@ -44,6 +44,14 @@ class MockDevice : public Device {
  MOCK_METHOD3(readImpl, bool(uint64_t, uint32_t, void*));
  MOCK_METHOD3(writeImpl, bool(uint64_t, uint32_t, const void*));
  MOCK_METHOD0(flushImpl, void());
+  MOCK_METHOD0(allocatePlacementHandle, int());
+
+  virtual bool writeImpl(uint64_t offset,


remove virtual here and add override instead. i.e., bool writeImpl(...) override {

This results in compilation error (due to gtest restrictions on default argument - int handle - I guess).
How about adding a line ?
MOCK_METHOD4(writeImpl, bool(uint64_t, uint32_t, const void*, int));

jaesoo-fb · 2023-12-15T20:19:57Z

cachelib/navy/common/FdpNvme.cpp

+  size_t bPos = blockDevice.find_last_of("/") + 1;
+  size_t pPos = blockDevice.find('p', bPos);
+
+  XDCHECK(bPos < std::string::npos);


Remove this.

arungeorge83 · 2023-12-18T13:03:49Z

Overall looks good. Thanks for the work.

Could you apply below patch?

diff --git a/fbcode/cachelib/navy/common/TARGETS b/fbcode/cachelib/navy/common/TARGETS
--- a/fbcode/cachelib/navy/common/TARGETS
+++ b/fbcode/cachelib/navy/common/TARGETS
@@ -7,6 +7,7 @@
     srcs = [
         "Buffer.cpp",
         "Device.cpp",
+        "FdpNvme.cpp",
         "Hash.cpp",
         "SizeDistribution.cpp",
         "Types.cpp",
@@ -15,6 +16,7 @@
         "Buffer.h",
         "CompilerUtils.h",
         "Device.h",
+        "FdpNvme.h",
         "Hash.h",
         "NavyThread.h",
         "SizeDistribution.h",
@@ -27,7 +29,6 @@
         "//folly:function",
         "//folly:thread_local",
         "//folly/experimental/io:async_io",
-        "//folly/experimental/io:io_uring",
         "//folly/hash:checksum",
         "//folly/hash:hash",
         "//folly/io/async:event_base_manager",
@@ -41,6 +42,8 @@
         "//folly:file",
         "//folly:portability",
         "//folly:range",
+        "//folly/experimental/io:async_base",
+        "//folly/experimental/io:io_uring",
         "//folly/fibers:core_manager",
         "//folly/fibers:fiber_manager_map",
         "//folly/fibers:timed_mutex",
@@ -50,4 +53,7 @@
         "//folly/lang:bits",
         "//folly/logging:logging",
     ],
+    exported_external_deps = [
+        ("liburing", None, "uring"),
+    ],
 )

I could not find the file TARGETS. Is it something not present in open source version?

jaesoo-fb · 2023-12-18T17:47:35Z

I could not find the file TARGETS. Is it something not present in open source version?

Yeah, this is for internal build. Please ignore.

jaesoo-fb · 2023-12-20T01:55:57Z

cachelib/navy/common/FdpNvme.cpp

+}
+
+bool isValidNvmeDevice(const std::string& fileName) {
+  return std::regex_match(fileName, std::regex("^/dev/nvme\\d+n\\d+(p\\d+)?$"));


Could you replace this with the equivalent (re2::RE2::FullMatch?) from RE2? https://github.com/google/re2

We cannot use regex_match due to its vulnerability to segfault https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582&fbclid=IwAR16Xwiru8QryYObTnoATM5WwCSTX9IRVorMwDxYq9E0sxrsBQTw-H1iKH4

facebook-github-bot · 2023-12-21T09:05:18Z

@arungeorge83 has updated the pull request. You must reimport the pull request before landing.

…nto Cachelib Summary: This commit adds the device layer support for NVMe-FDP semantics and adds the RUH-awareness feature of NVMe-FDP in the upper layers of Navy. This allows the BlockCache(large items) and BigHash(small items) of Navy to segregate their data streams in physical NAND media by using the FDP placement Identifiers. With this changes, the Cachelib can reduce the Device Write Amplification (WAF) significantly even in high SSD utilization scenarios ("nvmCacheSizeMB" above 50% of the SSD capacity) in most of the cachelib workloads. This commit introduces a 'placementHandle' concept for data placement, which can be used by both BC and BH of Navy on device write() calls, especially for FDP placements. The 'placementHandle' have to be allocated from the device. io_uring_cmd interface(through nvme char device) is used to send FDP directives to Linux kernel, as sending it through the conventional block interfaces is not suported yet. The user can select the NVMe block device (Namespace/partition) as usual (Ex: "nvmCachePaths": ["/dev/nvme0n1p1"]), and the cachelib will pick the corresponding NVMe char device internally. This commit adds a new config 'deviceEnableFDP' to enable FDP. The user needs to select this along with iOUring I/O Engine options. ("navyEnableIoUring": true, "navyQDepth": 1, "deviceEnableFDP": true). Signed-off-by: Arun George <[email protected]> Signed-off-by: Vikash Kumar <[email protected]>

facebook-github-bot · 2023-12-21T19:23:23Z

@jaesoo-fb has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

jaesoo-fb · 2024-01-22T19:50:57Z

cachelib/navy/common/Device.cpp

+        options.sqe128 = true;
+        options.cqe32 = true;


Actually, I cannot see the big_cqe is used anymore. Is this still needed?

right, we can remove the line "options.cqe32 = true;" for now. We don't have the big_cqe use cases in the current code.

@arungeorge83 Actually, I would like to remove this option completely. So, we don't need sqe128, either, right?

@jaesoo-fb Actually both sqe128 and cqe32 are mandatory for NVMe passthrough commands. Else the kernel NVMe driver will reject those ios.
Reference: https://elixir.bootlin.com/linux/latest/source/drivers/nvme/host/ioctl.c#L742, Iceber/iouring-go#21

Also from Kanchan Joshi's words (Author of the IO passthru patch - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=456cba386e94f22fa1b1426303fdcac9e66b1417),
NVMe passthrough commands are of 72 bytes in size. This can not fit into regular SQE. Therefore big SQE (128 bytes) is required.
Also passthrough commands may return more than one result to userspace. Returning addtional result is not possible with regular CQE. Hence big CQE is needed.

Thanks for clarification. Yeah, it looks clear here https://elixir.bootlin.com/linux/v6.7/source/drivers/nvme/host/ioctl.c#L742

jaesoo-fb · 2024-01-23T01:57:00Z

cachelib/navy/common/FdpNvme.h

+#ifndef CACHELIB_IOURING_DISABLE
+#include <liburing.h>
+#endif


FYI. Actually, we should not include liburing.h directly here due to some internal dependency issues causing test failures on some targets. I will remove this.

Ok.
Then should we include <liburing.h> through <folly/experimental/io/IoUring.h> which include <liburing.h> in the file?

@arungeorge83 Yeah, right. It will include the liburing.h from the repo instead of that installed on the system.

FYI, I am taking care of minor changes including those required for the internal build, so you don't need to update the commit.

facebook-github-bot · 2024-01-25T20:53:44Z

@jaesoo-fb merged this pull request in 009e89b.

jaesoo-fb · 2024-01-25T21:02:28Z

Submitted with the fixup b5d70a5

facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Nov 15, 2023

jaesoo-fb reviewed Nov 16, 2023

View reviewed changes

jaesoo-fb mentioned this pull request Nov 18, 2023

Adds the support for Flexible Data Placement(FDP) over NVMe into the Cachelib. #247

Closed

arungeorge83 force-pushed the fdp/fdp_upstream_PR2 branch from c68f234 to 3c649e9 Compare November 30, 2023 12:53

jaesoo-fb reviewed Dec 1, 2023

View reviewed changes

arungeorge83 force-pushed the fdp/fdp_upstream_PR2 branch from 3c649e9 to 4fa7366 Compare December 15, 2023 07:05

jaesoo-fb reviewed Dec 15, 2023

View reviewed changes

jaesoo-fb reviewed Dec 20, 2023

View reviewed changes

arungeorge83 force-pushed the fdp/fdp_upstream_PR2 branch from 4fa7366 to cabe1c2 Compare December 21, 2023 09:05

jaesoo-fb reviewed Jan 23, 2024

View reviewed changes

facebook-github-bot closed this in 009e89b Jan 25, 2024

facebook-github-bot added the Merged label Jan 25, 2024

		void setMaxWriteSize(uint32_t maxWriteSize) { maxWriteSize_ = maxWriteSize; }

		void setMaxIOSize(uint32_t maxIOSize) { maxIOSize_ = maxIOSize; }

		@@ -788,6 +844,32 @@ bool AsyncIoContext::submitIo(IOOp& op) {
		}

(PR2) Adds the support for Flexible Data Placement(FDP) over NVMe into the Cachelib #277

(PR2) Adds the support for Flexible Data Placement(FDP) over NVMe into the Cachelib #277

Conversation

arungeorge83 commented Nov 15, 2023 • edited Loading

jaesoo-fb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jaesoo-fb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arungeorge83 commented Nov 16, 2023

arungeorge83 commented Nov 16, 2023 • edited Loading

jaesoo-fb commented Nov 16, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arungeorge83 Dec 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arungeorge83 Dec 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arungeorge83 Dec 7, 2023 • edited Loading

Choose a reason for hiding this comment

facebook-github-bot commented Dec 6, 2023

facebook-github-bot commented Dec 6, 2023

facebook-github-bot commented Dec 15, 2023

facebook-github-bot commented Dec 15, 2023

jaesoo-fb left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arungeorge83 commented Dec 18, 2023

jaesoo-fb commented Dec 18, 2023

Choose a reason for hiding this comment

facebook-github-bot commented Dec 21, 2023

facebook-github-bot commented Dec 21, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

facebook-github-bot commented Jan 25, 2024

jaesoo-fb commented Jan 25, 2024

arungeorge83 commented Nov 15, 2023 •

edited

Loading

arungeorge83 commented Nov 16, 2023 •

edited

Loading

arungeorge83 Dec 4, 2023 •

edited

Loading

arungeorge83 Dec 4, 2023 •

edited

Loading

arungeorge83 Dec 7, 2023 •

edited

Loading

jaesoo-fb left a comment •

edited

Loading