Sunsetting librpmem, continuing librpma

26 views
Skip to first unread message

ppbb...@gmail.com

unread,
Dec 8, 2021, 6:04:56 AM12/8/21
to pmem
Hi all,
 
As some of you might know, PMDK has two distinct libraries for PMem over RDMA support - librpmem and librpma. The former was created many years ago to experiment with theoretical ideas the team had about remote persistence enabled by the combination of RDMA and PMem technologies. We've developed this library with the intention of using it as a remote replication mechanism for libpmemobj, our transactional object system. The resulting solution was not ideal since it married synchronous transactions with physical data replication. We don't think it is practical in this form, hence why, to this day, we still view librpmem and its libpmemobj integration as experimental. We also don't see much uptake of this functionality in the community. But mistakes are how you learn, so we don't consider this wasted effort. After all, it was an experiment with two unique technologies.
 
The result of all that learning is librpma - a far less restricting and generic abstraction for Remote Persistent Memory Access. The focus is no longer on synchronous replication but on simply allowing higher-level software to easily take advantage of PMem with RDMA without having to consider the intricacies of remote data durability.
 
This shift in approach is why, after much careful deliberation, we've decided to begin the process of sunsetting librpmem. We plan on deprecating all the APIs associated with this library in the next release of PMDK (1.12, targeted at late Q1/early Q2 next year). Once that's done, and we don't see much negative impact on the community, we will remove all rpmem functionality in the next release after that (PMDK 1.13).
 
Removing librpmem and its associated integration with PMDK will lessen the long-term maintenance burden on the team. It will allow us to pursue features and optimizations blocked by remote replication (e.g., internal lock-free persistent data structures). Removing this library will also reduce the existing user confusion of having two solutions that seemingly do the same thing.
 
We hope that, given the above context, our decision makes sense. But we understand that there might be different perspectives and use cases for librpmem that we didn't consider. Please let us know if you feel that we are acting too hastily or are a current user of librpmem and don't wish it deprecated. You can do that by answering this message or emailing me directly at piotr....@intel.com.
 
Piotr
Reply all
Reply to author
Forward
0 new messages