[ofiwg] libfabric 2.0 and FABRIC_DIRECT

[Xiong, Jianxin]

FABRIC_DIRECT is a building option that providers can choose to support or not. Providers are free to remove the support at any time. Middlewares are not required to test against fabric direct build. If they do, it is usually only done with the provider(s) in interest that support fabric direct. Even with all current providers removing fabric direct support, leaving the option available may be useful for future providers and doesn't incur any measurable maintenance cost by itself.

From: Blocksome, Michael <michael.blocksome at cornelisnetworks.com>
Sent: Tuesday, February 20, 2024 1:19 PM
To: ofiwg at lists.openfabrics.org; Xiong, Jianxin <jianxin.xiong at intel.com>
Subject: libfabric 2.0 and FABRIC_DIRECT

Hello all .. apologies, but I missed today's ofiwg call.

I understand that FABRIC_DIRECT w.r.t. libfabric 2.0 was discussed and it was determined that FABRIC_DIRECT would not be removed in the future.  @Xiong, Jianxin<mailto:jianxin.xiong at intel.com> - could you summarize the rationale for this decision for me?

In the current "version2" PR (https://github.com/ofiwg/libfabric/pull/9384) the only providers that support FABRIC_DIRECT are opx, psm2, psm3 and tcp - however opx will drop support, and the psm2 provider could be removed entirely (TBD).  The tcp provider is not optimized for latency (it is curious that it supports FABRIC_DIRECT at all). That leaves psm3 as the only provider that supports this feature. Does psm3 really need it? If not, then removing it would greatly simplify testing and maintenance costs - not just for ofiwg and the psm3 provider, but also for all middleware, etc.

Thanks!
Mike
External recipient
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20240220/2e0020bd/attachment-0001.htm>