Paper: CEIO: A Cache-Efficient Network I/O Architecture for NIC-CPU Data Paths
Authors: Bowen Liu, Xinyang Huang, Qijing Li, Zhuobin Huang, Yijun Sun, Wenxue Li, Junxue Zhang, Ping Yin, Kai Chen
Presenter: Yinchao Zhang, Tsinghua University
Guest of Honor: Xinyang Huang, The Hong Kong University of Science and Technology
Q: Which programming model does CIO use, and how can it control both raw Ethernet/DPDK traffic and RDMA traffic?
A: The same code path cannot control both traffic types because of limitations in the available NVIDIA programming interfaces. The implementation therefore uses different mechanisms for Ethernet and RDMA. On the RDMA side, the programmable DPA path is limited — for example, the speaker noted that they cannot handle RC traffic in the same way and can capture only certain UD-mode flows. In short, CIO combines multiple device-specific control paths rather than relying on one universal API.
Q: Did the research idea come from combining gaps found in previous papers, or from observing a real systems problem first?
A: The problem came first. The researchers were experimenting with a new high-speed ConnectX-7 NIC and trying to saturate its link rate with an end-to-end RPC system. Although synthetic traffic generators could drive the NIC much harder, the full receiver-side processing path achieved much lower throughput. That observation led them to investigate where the bottleneck came from. Only after observing the problem did they search the literature and use prior work to help reason about possible causes such as DDIO and last-level-cache contention.
Q: How difficult was it to identify the root cause, and how long did the whole project take?
A: Root-cause identification dominated the schedule. The speaker estimated that the entire project took roughly a year and a half, with close to a year spent understanding why the end-to-end system could not saturate the RDMA NIC. Once the root cause was understood, the actual design became much more straightforward. Implementation, experiments, and validation proceeded alongside that investigation, while the final paper writing took roughly two months.
Q: Was the evaluation intentionally limited, or was the project rushed?
A: The speaker argued that the evaluation was sufficient for the paper’s claims. The goal was not to maximize the number of experiments but to test the key observations, explain the design, and validate that the system addressed the identified bottleneck. In his view, additional experiments that did not help answer those points would not necessarily strengthen the work.
Q: What was the most challenging part of the research?
A: The research challenge was finding the true root cause of the throughput bottleneck. The implementation challenge was learning to program BlueField-3 SmartNICs, whose documentation and interfaces were difficult to work with. The team had already spent about a year building basic BlueField-3 infrastructure before this project, which reduced the amount of new implementation work needed for CIO itself.
Q: Is the implementation open source?
A: An early version of the code has already been released on GitHub. However, the speaker described it as an older version containing substantial hard-coded logic and said that it still needs to be updated before it fully reflects the current implementation.
Q: How many flows are needed to saturate a 400-Gbps-class setup, and does flow-table capacity become the bottleneck?
A: The speaker estimated that only a small number of flows — on the order of several to perhaps a few tens — can already saturate the link in their setup. The more important bottleneck is not the number of flow entries in the NIC but the host-side CPU work required to process RPCs, packets, retransmissions, acknowledgments, and related tasks. In one experiment, 16 flows were paired with 16 CPU cores.
Q: Could CIO be implemented purely in software on older or non-programmable NICs such as ConnectX-5?
A: A software implementation is possible in principle, but the speaker did not have a precise maximum-throughput number for it. The main concern is that DPU processing cores such as DPA or Arm cores are relatively weak for high-rate packet processing, especially for large messages. CIO therefore offloads operations such as counters and credits to hardware/RMT-style engines where possible. A more hardware-assisted implementation — for example using FPGA logic — could potentially execute the core control logic more efficiently.
Q: Would CIO change if it were implemented on other programmable NIC architectures such as AMD Pensando or FPGA-based SmartNICs?
A: Potentially. The speaker viewed more openly programmable packet-processing pipelines as attractive for this kind of control logic. AMD Pensando was mentioned as a potentially stronger research platform because of its programmable pipeline, while BlueField exposes less programmability for some RDMA paths. The answer was explicitly qualified because the speaker had not personally evaluated all of those alternative devices.
Q: Are the programmable RDMA-processing capabilities inside BlueField available to ordinary researchers?
A: Some capabilities exist internally but are not necessarily exposed through the public interface. The team had discussed these limitations with NVIDIA and had access to functionality that could not simply be released publicly. The speaker therefore distinguished between what the hardware may technically support and what external researchers can access through public firmware and SDKs.
Q: Could those internal capabilities become publicly available in future NVIDIA software releases?
A: Possibly. The speaker said NVIDIA had plans to expose more functionality over time and mentioned newer DOCA/PCC-related capabilities as examples of the direction. However, this was presented as an expectation rather than a firm product commitment, and the exact timing or feature set was not guaranteed in the discussion.