> There are multiple problems with libfrabric related to the use cases in my > area. Most of all the lack of multicast support. Then there is the build > up of software bloat on top. The interest here is in low latency > operations. Redenzvous and other new features are really not wanted if > they increase the latency.
Multicast is only supported by one vendor that has taken a hostile position against libfabric. Support for multicast will eventually be there, but it's definitely not a priority for me. As an open source project, anyone is welcome to propose patches. For native providers, libfabric will reduce latency. That's a provider implementation issue, and native providers will be available soon. The OFIWG selected to have a working set of interfaces that applications can begin using immediately, versus waiting until there were a large set of native providers. This is an entirely unrelated topic for this thread. Jason asked what I would do with libfabric. I answered. Your comments do nothing to change my mind on that answer. > This is a way it was implemented IMO, this is exactly the problem. The entire design is being driving by the implementation. That produces an unmaintainable API and fractures the software ecosystem, which is exactly where we are today. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
