[GH-ISSUE #76] Libfabric transport layer support #43

New issue

Closed

opened 2026-10-29 21:08:19 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-29 21:08:19 +00:00

Owner

Originally created by @xendo on GitHub (Jan 10, 2025).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/76

In your roadmap i can see that you plan to add additional transport layers for the transfer engine. I was wondering if you also considered adding support for libfabric: https://github.com/ofiwg/libfabric . That would give you support for several providers at a single try.

Is there anything I should be aware of before trying to implement and contribute such support?

P.S.
I really enjoyed reading through your documentation, really high quality stuff

Originally created by @xendo on GitHub (Jan 10, 2025). Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/76 In your roadmap i can see that you plan to add additional transport layers for the transfer engine. I was wondering if you also considered adding support for libfabric: https://github.com/ofiwg/libfabric . That would give you support for several providers at a single try. Is there anything I should be aware of before trying to implement and contribute such support? P.S. I really enjoyed reading through your documentation, really high quality stuff

bsakaguchi closed this issue

2026-10-29 21:08:20 +00:00

bsakaguchi commented

2026-10-29 21:08:21 +00:00

Author

Owner

@alogfans commented on GitHub (Jan 10, 2025):

As we have refactored the code recently, adding a new transport will be more easier. We appreicate the community to submit additional transports.

In my opinion, things to be aware before coding:

Current transfer API is one-sided. Though it is technically possible to extend it to support two-sided (send/recv) operations, we prefer to find approaches to make one-sided operations more efficient.
Most transport needs to manage metdata (e.g. segment info) by it self. You can refer to tcp transport at the beginning.

@alogfans commented on GitHub (Jan 10, 2025): As we have refactored the code recently, adding a new transport will be more easier. We appreicate the community to submit additional transports. In my opinion, things to be aware before coding: - Current transfer API is *one-sided*. Though it is technically possible to extend it to support two-sided (send/recv) operations, we prefer to find approaches to make one-sided operations more efficient. - Most transport needs to manage metdata (e.g. segment info) by it self. You can refer to `tcp` transport at the beginning.

bsakaguchi commented

2026-10-29 21:08:21 +00:00

Author

Owner

@stmatengss commented on GitHub (Jan 22, 2025):

@xendo It is already added to the Roadmap (#44 ). Thx.

@stmatengss commented on GitHub (Jan 22, 2025): @xendo It is already added to the Roadmap (#44 ). Thx.