Pith. sign in

REVIEW 4 major objections 5 minor 36 references

Swift: Rethinking RDMA Control Plane for Elastic Computing

T0 review · 4 major / 5 minor · reviewed 2026-08-09 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Swift shows that a user-space RDMA control plane, built on caching and fork, can match a kernel-space design's setup speed while far exceeding its data-plane throughput.

desk verdict Fork-start claim rests on an unmeasured path; the caching optimization and data-plane comparison are real, but the evaluation has gaps a referee should push on. read the letter →

arxiv 2501.19051 v1 pith:PPHC2BZE submitted 2025-01-31 cs.NI

Junxue Zhang , Han Tian , Xinyang Huang , Wenxue Li , Kaiqiang Xu , Dian Shen , Yong Wang , Kai Chen This is my paper · ORCID
classification cs.NI
keywords RDMAserverlesscomputingcontrolplanelibibverbsforkcachingelastickernelbypass
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that the two assumptions motivating kernel-space RDMA sharing for serverless computing are outdated: a user-space RDMA control plane is not inherently slow, and user-space RDMA resources can be shared through fork. It backs this with a cache-optimized libibverbs that cuts the connection-setup critical path from about 25 ms to about 2.2 ms, and with a fork-based queue-pair sharing scheme that adds roughly 100 µs on top of a normal fork. Swift, a user-space design co-implemented with OpenWhisk, delivers control-plane setup within 6.5% of the kernel-space KRCore across cold, warm, and fork starts, while achieving 30.56–46.50% higher throughput and 18.55–37.21% lower latency in the data plane. The upshot is that I/O-heavy serverless workloads can get RDMA's kernel-bypass benefits without the compatibility and security costs of a kernel-space control plane.

What carries the argument

The machinery has two parts. The first is a profiler-driven cache for libibverbs: it runs representative API sequences, identifies internal functions whose return values are stable (e.g., mlx5_is_sandy_bridge, which always returns 0 on modern CPUs), and generates an optimized library that short-circuits those calls to cached values. The second is fork-based RDMA resource sharing: Swift forks an INIT process that already owns the device context, protected domain, and a pool of pre-established RC queue pairs, and assigns queue pairs to child processes through two in-memory tables; the kernel's copy-on-fork for RDMA (available since 5.9.0-rc7, or via ibv_fork_init on earlier kernels) preserves correctness of memory registrations.

What would settle it

With Swift's cache warm, trigger a runtime condition that changes the value of a cached function—for example, move the container to a different CPU set, hot-add a NIC, or change the network namespace—and check whether the optimized libibverbs returns the stale cached value and whether queue-pair setup breaks.

Watch

Extended reading notes

Core claim

The central discovery is that the dominant cost in user-space RDMA connection setup is user-space library code, not kernel work. Profiling shows 23.4 ms of the 26.5 ms setup time is spent in libibverbs user space, with ibv_open_device alone accounting for over 90% of the time. Because many internal libibverbs functions return values that are stable across calls, the paper caches those return values and replaces the function calls with direct lookups, cutting ibv_open_device from 22.9 ms to 2.18 ms and the overall critical path to about 2.2 ms, an 11.4× improvement. The second part of the discovery is that fork, enabled by the kernel's copy-on-fork for RDMA, lets child processes inherit established RC queue pairs with only ~100 µs extra overhead, making fork-based serverless starts viable. Together these show that the microsecond-level kernel-space control plane of KRCore, with its data-plane penalty, is avoidable.

Load-bearing premise

The largest assumption is that internal libibverbs functions return the same values every time they are called, so cached results stay valid across all runtime conditions, including device hotplug, network namespace changes, and per-container resource limits; if any cached function's return value changes, the optimized library serves stale data and connection setup can fail.

Editorial extensions

If this is right

  • In cold starts, where container launch dominates (about 318 ms), the choice of RDMA control plane barely affects end-to-end time, so microsecond-level optimization is unnecessary for that scenario.
  • For warm starts, the cache-optimized libibverbs brings RDMA setup within about 2.2% of a no-RDMA baseline, letting serverless platforms include RDMA without a kernel control plane.
  • For fork starts, sharing pre-established RC queue pairs via fork keeps overhead within 6.5% of a plain Python fork, enabling millisecond-level RDMA-aware task startup.
  • Because Swift keeps the data plane kernel-bypassed in user space, it avoids the up-to-75% data-plane loss reported for KRCore and runs on multiple kernel versions rather than one patched version.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The profiler-driven caching idea could generalize to other user-space libraries whose API results depend on slow, rarely changing environment checks, such as DPDK or SPDK control paths, not just libibverbs.
  • The paper's time-scale argument implies control-plane optimization for serverless should be priced against task startup time; that could refocus research from microsecond connection setup toward pipelining setup behind runtime initialization, which Swift mentions but does not fully evaluate.
  • A production deployment of the cache would need explicit invalidation on device hotplug, network namespace changes, or driver updates; the paper describes error-triggered re-profiling but does not test these failure modes.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes Swift, a user-space RDMA control plane design for elastic/serverless computing. Swift combines a cache-optimized libibverbs library for cold and warm starts with fork-based sharing of RDMA resources for fork starts, and compares itself against the kernel-space KRCore system. The central claim is that Swift delivers 30.56--46.50% higher data-plane throughput and 18.55--37.21% lower latency than KRCore while incurring only about 6.5% control-plane overhead, while also being more portable across kernel versions. The evaluation covers optimized libibverbs API latency, control-plane end-to-end times for cold/warm/fork starts, data-plane throughput and latency for one- and two-sided operations, and kernel compatibility.

Significance. If the claims hold, the paper offers a simple and practical alternative to kernel-space RDMA sharing for serverless platforms: it would show that user-space connection setup can be made fast enough through caching and that fork can share RDMA resources without kernel modifications, thereby avoiding the data-plane penalty and compatibility problems of KRCore. The work is empirical and includes a concrete prototype on OpenWhisk, comparisons against both unmodified libibverbs and KRCore, and a compatibility matrix across kernel versions. The strengths are the breadth of the control-plane and data-plane measurements and the explicit requirements analysis in Section 3.1. However, several load-bearing evaluation gaps—most notably the unmeasured new-destination fork path, the unverified caching safety assumption, and the confounded data-plane comparison—currently prevent the paper from fully supporting its headline claims. The central idea is defensible, but the evidence needs strengthening before the claims can be taken at face value.

major comments (4)
  1. [§5.3.3, Figure 7c; §4.1.3] The fork-start evaluation does not exercise the path where the forked child needs to establish a connection to a new destination. Section 4.1.3 describes that if the INIT process has not set up the required connection, Swift picks an unassigned QP and establishes the connection, which involves ibv_modify_qp and an endpoint handshake. The experiment in Section 5.3.3 measures the time from invoking fork until the RDMA connection is set up, but only for the case where the INIT process already holds a connected RC QP to the requested destination, as implied by the pre-establishment design in Section 4.1.2. The end-to-end latency of the new-destination path is never reported, so the less-than-100µs control-plane budget for fork starts in Section 3.1 is not validated for the general serverless case in which a forked function may be directed to a service the parent has not contacted. Please measure the new-destination fork-start path explicitly, or provide a scaling argument showing that pre-establishing all pairwise QPs is feasible for the intended workloads.
  2. [§3.3] The caching optimization replaces internal libibverbs function calls with cached return values based on the observation that these functions "tend to return consistent values across multiple calls." The paper does not formally verify under which conditions this invariance holds, nor does it stress-test the effect of device hotplug, network namespace changes, per-container CPU or memory limits, or kernel/driver updates. A stale cached value could silently corrupt connection setup, and the described periodic/error-driven re-profiling is not evaluated. Please either provide a correctness argument bounding the conditions under which the cached values remain valid, or add a stress test that mutates the relevant system state and demonstrates that the cache does not return stale values.
  3. [§5.1, §5.4] The data-plane comparison in Section 5.4 is confounded by the software stack: Swift and unmodified libibverbs run on Ubuntu 22.04 with kernel 5.15.0, while KRCore runs on Ubuntu 18.04 with kernel 4.15.0-46-generic, as Section 5.1 states. The reported 30.56--46.50% throughput improvement and 18.55--37.21% latency reduction could therefore be due in part to differences in kernel, drivers, or network stack configuration rather than to the user-space-versus-kernel-space data path. Please run both schemes on the same kernel and driver version if possible, or report a controlled comparison that isolates the effect of the data-plane mechanism from the effect of the operating system environment.
  4. [§3.1, §5.3.3] There is an inconsistency between the requirement analysis and the measured result. Section 3.1 states that for fork-based task startup the RDMA control-plane overhead should be less than 100µs, making the overhead impact less than 5% of overall performance. Section 5.3.3 reports that Swift is 6.5% slower than the fork baseline and 5.1% slower than KRCore, which exceeds the stated 5% threshold. The paper later describes this as "within approximately 6.5% of the optimal solution," but this does not reconcile the discrepancy. Please either adjust the requirement threshold with a concrete justification or provide a revised analysis that accounts for the measured 6.5% overhead.
minor comments (5)
  1. [§5.3, §5.4] All results are reported as averages of 10 runs, but the figures do not show error bars, confidence intervals, or per-run variance; please add this information or state the observed spread so that the reader can judge the stability of the reported differences.
  2. [§5.4.1] There is a typo in the first sentence of the RDMA READ results: "the throughput achievedx" should read "the throughput achieved."
  3. [Table 1] The notation "✓ ∗" in the compatibility table is not defined in the caption; please clarify what "compatible with minor modification" covers and why libibverbs also falls into this category on older kernels.
  4. [§4.3, §5.5] Section 4.3 states that there are no modules tightly coupled to a specific Linux kernel version, but Section 5.5 notes that Swift requires minor modifications for kernel versions earlier than 5.9.0-rc7, using ibv_fork_init; please make the statement in Section 4.3 consistent with this qualification.
  5. [§4.2] The security discussion asserts that Swift offers "robust security for elastic computing tasks" based on container isolation, but this is not compared empirically with KRCore or with other container-based serverless platforms; please either soften the claim or provide supporting evidence.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central claims are empirical comparisons against external baselines (KRCore and official libibverbs), and the caching/fork insights are measured optimizations, not fitted predictions.

full rationale

Swift's derivation chain is empirical rather than circular. The two enabling claims—that user-space RDMA control plane setup can be accelerated by caching internal libibverbs calls, and that RDMA resources can be shared via fork—are supported by direct measurements (e.g., ibv_open_device reduced from 22.9 ms to 2.18 ms, critical path reduced to ~2.2 ms, copy-on-fork overhead ~100 us) against unmodified libibverbs and kernel-space KRCore. The caching design profiles functions and replaces consistent-return calls with cached values; the reported speedups are measurements of that implemented optimization, not predictions statistically forced by a fitted parameter. The requirements analysis in Section 3.1 sets overhead budgets (several ms for warm starts, <100 us for fork starts) and Swift's measured overhead is then compared against those budgets; this is a design-target comparison, not a derivation that assumes its conclusion. The only author-overlapping citation is [28] (SRNIC) used to justify the RC-vs-DCT design choice regarding RNIC memory bottlenecks; this is a real, externally published system result, is not load-bearing for the central throughput/latency claims, and does not constitute circular support. A genuine evaluation limitation exists—the fork-start benchmark in Section 5.3.3 measures a fork of an INIT process that already holds a connected RC QP, while Section 4.1.3's new-destination setup path is not separately end-to-end measured—but this is an evidence gap, not a circular reduction of the claims to their inputs. The paper is self-contained against external baselines, so the appropriate circularity score is 0.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The central claim rests on a handful of empirical assumptions: typical serverless startup latencies, the safety of memoizing libibverbs calls, and the correctness of fork-based QP sharing. The 5% overhead threshold is a hand-chosen target that the paper's own fork-start result exceeds.

free parameters (2)
  • overhead_impact_threshold = 5%
    Section 3.1 states that an RDMA control plane overhead keeping the impact below 5% of total task launch time is sufficient. This 5% threshold is chosen by the authors without derivation, and it is used to justify that a few milliseconds (warm) and below 100 microseconds (fork) are acceptable targets.
  • warm_start_target_overhead = several milliseconds
    Section 3.1 asserts that several milliseconds of RDMA setup is acceptable for warm starts so that impact stays below 5%; this target is derived from the measured 89ms warm-start baseline on the testbed. On a platform with much faster warm starts, the same overhead would exceed the 5% impact threshold.
assumptions (4)
  • domain assumption RDMA control plane setup in user space typically takes 16-34 ms, as reported in cited prior work.
    Used as the baseline for the problem setup in Section 2.3.
  • ad hoc to paper Caching return values of internal libibverbs functions is safe for the profiled functions across all runtime conditions.
    Section 3.3 replaces function calls with cached return logic. The paper does not formally prove that the profiled 'consistent' return values cannot change (e.g., device hotplug, cgroup changes). This is a load-bearing correctness assumption.
  • domain assumption Fork can share RDMA queue pairs between parent and child processes without explicit re-registration, except for the copy-on-fork overhead.
    Section 3.4 relies on the kernel's copy-on-fork support for RDMA. The paper measures the overhead but does not test all drivers or edge cases such as concurrent posting by parent and child.
  • domain assumption The warm-start baseline is about 89ms and fork-start baseline is about 1.38ms on the testbed.
    Used in Section 5.3 to compute relative overheads. These numbers are specific to the testbed and may not generalize to other serverless platforms.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Swift: Rethinking RDMA Control Plane for Elastic Computing." pith.science (2026). https://pith.science/paper/PPHC2BZE

@misc{pith2026250119051,
  author       = {Pith},
  title        = {Pith review of: Swift: Rethinking RDMA Control Plane for Elastic Computing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PPHC2BZE}},
  note         = {Machine review of arXiv:2501.19051}
}
read the original abstract

Elastic computing enables dynamic scaling to meet workload demands, and Remote Direct Memory Access (RDMA) enhances this by providing high-throughput, low-latency network communication. However, integrating RDMA into elastic computing remains a challenge, particularly in control plane operations for RDMA connection setup. This paper revisits the assumptions of prior work on high-performance RDMA for elastic computing, and reveals that extreme microsecond-level control plane optimizations are often unnecessary. By challenging the conventional beliefs on the slowness of user-space RDMA control plane and the difficulty of user-space RDMA resource sharing, we uncover new design opportunities. Our key insight is that user-space RDMA connection setup can be significantly improved with caching, while RDMA resources can be efficiently shared among processes using fork. In light of this, we propose Swift, a simple yet effective solution that co-designs RDMA with a serverless framework to optimize performance for elastic computing. At its very core, Swift handles cold and warm serverless requests by swiftly initializing the RDMA control plane with cache-optimized libibverbs, and manages fork requests by leveraging the RDMA's fork capability. Implemented with OpenWhisk, Swift delivers 30.56-46.50% higher average throughput and 18.55-37.21% lower latency, at a cost of 6.5% control plane overhead, compared to prior solutions.

Figures

Figures reproduced from arXiv: 2501.19051 by the authors.

Figure 1
Figure 1. Critical Path of RDMA in Elastic Computing: [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. presents a detailed breakdown of the libibverbs workflow during RDMA control plane setup, encompassing API Calls ibv_get_device_list ibv_open_device ibv_alloc_pd ibv_reg_mr ibv_create_qp ibv_modify_qp RNIC initial parameter setup preliminary checks device initialization kernel resource maintenance channel setup User-space Kernel-space Execution Time： 23.4ms 3.1ms Total: 26.5ms [PITH_FULL_IMAGE:figures/full_fig_p005… view at source ↗
Figure 3
Figure 3. Workflow of proposed caching mechanism. both user-space and kernel-space operations. In this workflow, the user-space component is primarily responsible for initial parameter configuration, preliminary checks, and other non￾critical tasks. In contrast, the kernel-space component handles critical operations, such as device initialization, resource allo￾cation, and communication channel setup. The results illustrate t… view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Workflow of Swift. The workflow of each request is marked with a different color. to handle the requests. Please note, as conventional serverless computing, we only use containers for requests that belong to the container owner for security concern (more details in §4.…
Figure 5
Figure 5. Figure 5: Relationship of tables used in Swift. lished, also using the index as the QP ID (the middle table in [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Comparison of libibverbs Performance. • libibverbs: We adopt the unmodified official libibverbs from RDMA Core User-space Libraries and Daemons (version 52.0) [19]. We use libibverbs alone with the standard Mellanox OFED software [23]. • KRCore: KRCore operates primari…
Figure 7
Figure 7. Figure 7: Performance of RDMA Control Plane allocating more CPUs does not lead to better performance. In contrast, Figure 6b demonstrates the performance of our optimized libibverbs. We note that by leveraging caching optimization mechanisms, the most notable improvement is in i…
Figure 8
Figure 8. Figure 8: Performance of RDMA One-sided READ 0 5 10 15 20 25 Thread Number 0.0 0.2 0.4 0.6 0.8 1.0 Throughput (Op/s) 1e7 Swift KRCore (a) Throughput [sync] 0 5 10 15 20 25 Thread Number 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Latency ( s) Swift KRCore (b) Latency [sync] 0 5 10 15 20 25 Thre…
Figure 9
Figure 9. Figure 9: Performance of RDMA One-sided WRITE 5.4 Data Plane Performance In this section, we evaluate the data plane performance of Swift by considering both throughput and latency for one￾sided and two-sided RDMA operations. Similar to previous work [30], we evaluate both sync …
Figure 10
Figure 10. Figure 10: Performance of RDMA Two-sided SEND/RECEIVE [PITH_FULL_IMAGE:figures/full_fig_p012_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

36 extracted references · 35 canonical work pages

  1. [1]

    SAND: towards high- performance serverless computing

    Istemi Ekin Akkus, Ruichuan Chen, Ivica Rimac, Manuel Stein, Klaus Satzke, Andre Beck, Paarijaat Aditya, and V olker Hilt. SAND: towards high- performance serverless computing. In Haryadi S. Gu- nawi and Benjamin C. Reed, editors, Proceedings of the 2018 USENIX Annual Technical Conference, USENIX ATC 2018, Boston, MA, USA, July 11-13, 2018, pages 923–935....

    work page 2018

  2. [2]

    Elasticity in cloud computing: State of the art and research challenges

    Yahya Al-Dhuraibi, Fawaz Paraiso, Nabil Djarallah, and Philippe Merle. Elasticity in cloud computing: State of the art and research challenges. IEEE Trans. Serv. Comput., 11(2):430–447, 2018

    work page 2018

  3. [3]

    AWS Lambda

    Amazon Web Services. AWS Lambda. https://aws. amazon.com/lambda/, 2024. Accessed: 2024-07-05

    work page 2024

  4. [4]

    OpenWhisk: Open Source Serverless Cloud Platform

    Apache OpenWhisk Development Team. OpenWhisk: Open Source Serverless Cloud Platform. https:// openwhisk.apache.org, 2024. Accessed: 2024-07- 17

    work page 2024

  5. [5]

    From warm to hot starts: leveraging runtimes for the serverless era

    João Carreira, Sumer Kohli, Rodrigo Bruno, and Pedro Fonseca. From warm to hot starts: leveraging runtimes for the serverless era. In Sebastian Angel, Baris Kasikci, and Eddie Kohler, editors,HotOS ’21: Workshop on Hot Topics in Operating Systems, Ann Arbor, Michigan, USA, June, 1-3, 2021, pages 58–64. ACM, 2021

    work page 2021

  6. [6]

    The new linux’perf’tools

    Arnaldo Carvalho De Melo. The new linux’perf’tools. In Slides from Linux Kongress, volume 18, pages 1–42, 2010

    work page 2010

  7. [7]

    Cat- alyzer: Sub-millisecond startup for serverless computing with initialization-less booting

    Dong Du, Tianyi Yu, Yubin Xia, Binyu Zang, Guanglu Yan, Chenggang Qin, Qixuan Wu, and Haibo Chen. Cat- alyzer: Sub-millisecond startup for serverless computing with initialization-less booting. In James R. Larus, Luis Ceze, and Karin Strauss, editors, ASPLOS ’20: Archi- tectural Support for Programming Languages and Op- erating Systems, Lausanne, Switzerl...

    work page 2020

  8. [8]

    Fission: Open source Kubernetes-native Serverless Framework

    Fission Development Team. Fission: Open source Kubernetes-native Serverless Framework. https:// fission.io, 2024. Accessed: 2024-07-17

    work page 2024

Show all 36 references
  1. [9]

    Above the clouds: A berkeley view of cloud computing

    Armando Fox, Rean Griffith, Anthony Joseph, Randy Katz, Andrew Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia. Above the clouds: A berkeley view of cloud computing. Dept. Electrical Eng. and Comput. Sciences, University of Cal- ifornia, Berk...

    2009

  2. [10]

    Faascache: keeping serverless computing alive with greedy-dual 13 caching

    Alexander Fuerst and Prateek Sharma. Faascache: keeping serverless computing alive with greedy-dual 13 caching. In Tim Sherwood, Emery D. Berger, and Chris- tos Kozyrakis, editors, ASPLOS ’21: 26th ACM Inter- national Conference on Architectural Support for Pro- gramming Langu...

    2021

  3. [11]

    The ebpf runtime in the linux kernel

    Bolaji Gbadamosi, Luigi Leonardi, Tobias Pulls, Toke Høiland-Jørgensen, Simone Ferlin-Reiter, Simo Sorce, and Anna Brunström. The ebpf runtime in the linux kernel. CoRR, abs/2410.00026, 2024

    2024 arXiv

  4. [12]

    RDMA over commodity ethernet at scale

    Chuanxiong Guo, Haitao Wu, Zhong Deng, Gaurav Soni, Jianxi Ye, Jitu Padhye, and Marina Lipshteyn. RDMA over commodity ethernet at scale. In Marinho P. Barcel- los, Jon Crowcroft, Amin Vahdat, and Sachin Katti, edi- tors, Proceedings of the ACM SIGCOMM 2016 Confer- ence, Floria...

    2016

  5. [13]

    Zenix: Efficient execution of bulky serverless applications, 2024

    Zhiyuan Guo, Zachary Blanco, Junda Chen, Jinmou Li, Zerui Wei, Bili Dong, Ishaan Pota, Mohammad Shahrad, Harry Xu, and Yiying Zhang. Zenix: Efficient execution of bulky serverless applications, 2024

    2024

  6. [14]

    Arpaci-Dusseau, and Remzi H

    Tyler Harter, Brandon Salmon, Rose Liu, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau. Slacker: Fast distribution with lazy docker containers. In Angela Demke Brown and Florentina I. Popovici, editors, 14th USENIX Conference on File and Storage Technologies, FAST 2016,...

    2016

  7. [15]

    Masq: RDMA for virtual private cloud

    Zhiqiang He, Dongyang Wang, Binzhang Fu, Kun Tan, Bei Hua, Zhi-Li Zhang, and Kai Zheng. Masq: RDMA for virtual private cloud. In Henning Schulzrinne and Vishal Misra, editors, SIGCOMM ’20: Proceedings of the 2020 Annual conference of the ACM Special Interest Group on Data Comm...

    2020

  8. [16]

    Megascale: Scaling large language model training to more than 10, 000 gpus

    Ziheng Jiang, Haibin Lin, Yinmin Zhong, Qi Huang, Yangrui Chen, Zhi Zhang, Yanghua Peng, Xiang Li, Cong Xie, Shibiao Nong, Yulu Jia, Sun He, Hongmin Chen, Zhihao Bai, Qi Hou, Shipeng Yan, Ding Zhou, Yiyao Sheng, Zhuo Jiang, Haohan Xu, Haoran Wei, Zhang Zhang, Pengfei Nie, Leqi...

    2024

  9. [17]

    Andersen

    Anuj Kalia, Michael Kaminsky, and David G. Andersen. Fasst: Fast, scalable and simple distributed transactions with two-sided (RDMA) datagram rpcs. In Kimberly Keeton and Timothy Roscoe, editors,12th USENIX Sym- posium on Operating Systems Design and Implementa- tion, OSDI 201...

    2016

  10. [18]

    Freeflow: Software-based virtual RDMA networking for container- ized clouds

    Daehyeok Kim, Tianlong Yu, Hongqiang Harry Liu, Yibo Zhu, Jitu Padhye, Shachar Raindel, Chuanxiong Guo, Vyas Sekar, and Srinivasan Seshan. Freeflow: Software-based virtual RDMA networking for container- ized clouds. In Jay R. Lorch and Minlan Yu, editors, 16th USENIX Symposium...

    2019

  11. [19]

    RDMA Core 52.0

    Linux-RDMA. RDMA Core 52.0. https:// github.com/linux-rdma/rdma-core/releases/ tag/v52.0, 2024. Accessed: 2024-07-23

    2024

  12. [20]

    Oc- topus: an rdma-enabled distributed persistent memory file system

    Youyou Lu, Jiwu Shu, Youmin Chen, and Tao Li. Oc- topus: an rdma-enabled distributed persistent memory file system. In Dilma Da Silva and Bryan Ford, edi- tors, Proceedings of the 2017 USENIX Annual Technical Conference, USENIX ATC 2017, Santa Clara, CA, USA, July 12-14, 2017,...

    2017

  13. [21]

    Mellanox ASAP2 Accelerated Switching and Packet Processing

    Mellanox. Mellanox ASAP2 Accelerated Switching and Packet Processing. https://network.nvidia.com/ files/doc-2020/sb-asap2.pdf, 2024. Accessed: 2024-07-19

    2020

  14. [22]

    Dynamically Connected (DC) QPs

    NVidia. Dynamically Connected (DC) QPs. https://docs.nvidia.com/networking/display/ rdmacore50/dynamically+connected+(dc)+qps,

  15. [23]

    Mellanox OFED

    NVIDIA. Mellanox OFED. https:// network.nvidia.com/products/infiniband- drivers/linux/mlnx_ofed/, 2024. Accessed: 2024-07-23

    2024

  16. [24]

    Arpaci-Dusseau, and Remzi H

    Edward Oakes, Leon Yang, Dennis Zhou, Kevin Houck, Tyler Harter, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau. SOCK: rapid task provisioning with serverless-optimized containers. In Haryadi S. Gunawi and Benjamin C. Reed, editors, Proceedings of the 2018 USENIX Annual...

    2018

  17. [25]

    Pentakalos

    Odysseas I. Pentakalos. An introduction to the in- finiband architecture. In 28th International Computer Measurement Group Conference, December 8-13, 2002, 14 Reno, Nevada, USA, Proceedings, pages 425–432. Com- puter Measurement Group, 2002

    2002

  18. [26]

    Fast and concurrent RDF queries with rdma- based distributed graph exploration

    Jiaxin Shi, Youyang Yao, Rong Chen, Haibo Chen, and Feifei Li. Fast and concurrent RDF queries with rdma- based distributed graph exploration. In Kimberly Kee- ton and Timothy Roscoe, editors, 12th USENIX Sympo- sium on Operating Systems Design and Implementation, OSDI 2016, S...

    2016

  19. [27]

    LITE kernel RDMA support for datacenter applications

    Shin-Yeh Tsai and Yiying Zhang. LITE kernel RDMA support for datacenter applications. In Proceedings of the 26th Symposium on Operating Systems Principles, Shanghai, China, October 28-31, 2017, pages 306–324. ACM, 2017

    2017

  20. [28]

    SRNIC: A scalable architecture for RDMA nics

    Zilong Wang, Layong Luo, Qingsong Ning, Chaoliang Zeng, Wenxue Li, Xinchen Wan, Peng Xie, Tao Feng, Ke Cheng, Xiongfei Geng, Tianhao Wang, Weicheng Ling, Kejia Huo, Pingbo An, Kui Ji, Shideng Zhang, Bin Xu, Ruiqing Feng, Tao Ding, Kai Chen, and Chuanxiong Guo. SRNIC: A scalabl...

    2023

  21. [29]

    Fast rdma- based ordered key-value store using remote learned cache

    Xingda Wei, Rong Chen, and Haibo Chen. Fast rdma- based ordered key-value store using remote learned cache. In 14th USENIX Symposium on Operating Sys- tems Design and Implementation, OSDI 2020, Virtual Event, November 4-6, 2020, pages 117–135. USENIX Association, 2020

    2020

  22. [30]

    KRCORE: A microsecond-scale RDMA control plane for elastic computing

    Xingda Wei, Fangming Lu, Rong Chen, and Haibo Chen. KRCORE: A microsecond-scale RDMA control plane for elastic computing. In Jiri Schindler and Noa Zilber- man, editors, 2022 USENIX Annual Technical Confer- ence, USENIX ATC 2022, Carlsbad, CA, USA, July 11- 13, 2022, pages 121...

    2022

  23. [31]

    No provi- sioned concurrency: Fast rdma-codesigned remote fork for serverless computing

    Xingda Wei, Fangming Lu, Tianxia Wang, Jinyu Gu, Yuhan Yang, Rong Chen, and Haibo Chen. No provi- sioned concurrency: Fast rdma-codesigned remote fork for serverless computing. In Roxana Geambasu and Ed Nightingale, editors, 17th USENIX Symposium on Operating Systems Design an...

    2023

  24. [32]

    Introduction to the infiniband core soft- ware

    Bob Woodruff, Sean Hefty, Roland Dreier, and Hal Rosenstock. Introduction to the infiniband core soft- ware. In Linux symposium, volume 2, pages 271–282, 2005

    2005

  25. [33]

    Characterizing serverless platforms with serverlessbench

    Tianyi Yu, Qingyuan Liu, Dong Du, Yubin Xia, Binyu Zang, Ziqian Lu, Pingchao Yang, Chenggang Qin, and Haibo Chen. Characterizing serverless platforms with serverlessbench. In Rodrigo Fonseca, Christina De- limitrou, and Beng Chin Ooi, editors, SoCC ’20: ACM Symposium on Cloud ...

    2020

  26. [34]

    Beehive: Sub-second elasticity for web services with semi-faas execution

    Ziming Zhao, Mingyu Wu, Jiawei Tang, Binyu Zang, Zhaoguo Wang, and Haibo Chen. Beehive: Sub-second elasticity for web services with semi-faas execution. In Tor M. Aamodt, Natalie D. Enright Jerger, and Michael M. Swift, editors, Proceedings of the 28th ACM International Confer...

    2023

  27. [517]

    USENIX Association, 2023

    2023

  28. [2024]

    Accessed: 2024-07-08

    2024

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.