GitHub user morristai added a comment to the discussion: RDMA support
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. GitHub link: https://github.com/apache/opendal/discussions/7421#discussioncomment-16656631 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
