RDMA support

[dentiny]

Hi team, I'm wondering if there's any chance to support RDMA in the project.

Context: in high bandwidth environment it's hard to fully utilize the b/w with TCP stack.
For example, we have 40~50GBps (two DCs) single-node-to-node b/w, but after tuning TCP parameters we're still only able to get 27GBps. We have RDMA client development in parallel, which easily reaches 80-90% of b/w.

For example, valkey go client has supported RDMA: https://github.com/valkey-io/valkey-go/tree/main/valkeyrdma
Implementation-wise, it's adding a new code path for net.Conn interface.

[morristai]

Thanks for raising this.

OpenDAL does not support RDMA today, and it's unlikely to land as a core-level feature. The reason is that OpenDAL is a storage abstraction without a single swappable transport layer — unlike the valkey-go example you linked, where net.Conn is the natural seam. In OpenDAL, the transport is backend-specific:

• S3/GCS/OSS and similar services are HTTP-based, and the server side would also need to speak RDMA for any client-side change to matter
• some backends wrap a native client library (HDFS, RocksDB, …), where RDMA support depends on that library, not on us
• fs is based on local/POSIX filesystem semantics

That said, RDMA can still make sense in two shapes:

1. The underlying filesystem already uses RDMA internally (e.g. Lustre, GPFS, NFS-over-RDMA). OpenDAL benefits indirectly via the fs service as long as it's mounted and exposed through POSIX.
2. A specific storage system provides its own RDMA-native protocol. The right direction there is a dedicated backend for that system, rather than a cross-cutting change in core.

Out of curiosity — what's the storage system on the other end of your RDMA client? That would help a lot in figuring out whether this fits as a new service, an extension to an existing one, or something else.

[Xuanwo]

There is a related discussion: #5090