[ofiwg] OFIWG 6/16/2026 Meeting Minutes

[Xiong, Jianxin]

6/16/2026

Generated by AI assistant with manual typo fixes.

Participants

Bob Cernohous (Cornelis Networks)
Howard Pritchard
Jianxin Xiong (Working Group Chair, Intel)
John Byrne [HPE]
Ken Raffenetti (Cornelis)
Lindsay Reiser [Cornelis Networks]
Rajalaxmi (Intel)
Sai Sunku [AWS]
Seth Zegelstein [AWS]
Shi Jin (AWS)
Stephen Oost (Intel)
Steven Vormwald (US - HPE)
Zach Dworkin (Intel)

Overview

The meeting was led by the Working Group Chair with active participation from AWS representatives including Seth Zegelstein, Shi Jin, and Sai Sunku. The primary focus was on the upcoming v2.6.0 release schedule and a detailed discussion of a pull request concerning error completions for matched but incomplete receives in the messaging interface. The group examined the feasibility and implications of guaranteeing error completions from providers, especially in failure scenarios such as sender crashes or undetected errors. AWS contributors highlighted the challenges in enforcing strict semantics across different providers and protocols, noting that some providers can detect disconnections and generate error completions, while others cannot. The consensus was to avoid imposing rigid requirements in the main specification and instead address provider-specific behaviors, particularly for the EFA provider, through dedicated documentation and offline discussions. The meeting concluded with agreement to close the PR and continue refining the approach outside the main working group sessions.

Detailed Summary

Release Update and Schedule
The Working Group Chair provided an update on the v2.6.0 release schedule, noting a one-week delay in the Release Candidate (RC2) due to performance tuning on the shared memory provider. The RC2 release occurred on the past Monday, with the General Availability (GA) expected on June 22nd. No major changes are anticipated between RC2 and GA except for critical bug fixes.

  *   Working Group Chair stated the RC2 release was delayed by a week due to performance tuning.

  *   The RC2 release was pushed out on Monday, with GA expected June 22nd.

  *   No major changes expected between RC2 and GA except important bug fixes.

PR Discussion on fi_msg and fi_tagged
The group discussed a pull request (PR) proposing to add a sentence to the man page regarding the fi_msg and fi_tagged. The PR aims to guarantee that if a receive is matched but cannot complete, the application will always receive an error completion. This guarantee could simplify application logic but raises concerns about the provider's effort to meet this requirement and the feasibility in certain failure scenarios.

  *   Working Group Chair introduced the PR about error completions for matched but incomplete receives.

  *   The PR intends to guarantee applications receive error completions in such cases.

  *   Concerns were raised about the provider's ability to fulfill this guarantee under all conditions.

Provider Behavior and Error Completion Guarantees
AWS representatives discussed the expected behavior of providers when handling matched receives that fail to complete. They emphasized that receives are matched in posting order but completions may not be ordered. The group debated whether providers should be required to generate error completions explicitly when a matched receive cannot complete due to errors, and how this affects application state clarity. The difficulty of guaranteeing error completions in cases where the sender crashes or the receiver is unaware of failures was highlighted.

  *   [AWS] Seth Zegelstein explained receives are matched in posting order but completions are unordered.

  *   Seth emphasized the need for explicit error completions to avoid silent requeueing by providers.

  *   Shi Jin (AWS) noted that if the sender crashes, the receiver may not detect the failure to generate error completions.

  *   Sai Sunku (AWS) suggested wording that allows providers to generate error completions optionally.

  *   The group agreed that guaranteeing error completions in all failure cases is challenging.

Challenges in Detecting Sender Failures
The participants discussed scenarios where the sender crashes or fails to send control messages, making it impossible for the receiver to detect the failure and generate error completions. They acknowledged that some providers have mechanisms to detect disconnections and flush pending receives with errors, but this is not universal. The group considered the implications for connected versus unconnected protocols and the limitations of hardware notification mechanisms.

  *   Shi Jin (AWS) highlighted the difficulty of ensuring error completions when the sender crashes unexpectedly.

  *   Working Group Chair noted that some providers detect disconnections and generate error completions for pending receives.

  *   The group distinguished between connected protocols, which can detect failures, and unconnected protocols, which lack such mechanisms.

  *   It was acknowledged that enforcing strict semantics on providers may be impractical due to these limitations.

Next Steps and PR Handling
Given the complexities and limitations discussed, the group agreed not to enforce strict error completion semantics in the main specification. Instead, the PR will be closed and the discussion will continue specifically for the EFA provider documentation. Further offline discussions are planned to clarify expectations and behaviors for providers like EFA.

  *   Working Group Chair agreed not to enforce strict error completion guarantees in the main spec.

  *   [AWS] Seth Zegelstein proposed closing the PR and focusing on EFA provider documentation.

  *   Sai Sunku (AWS) and Seth agreed to continue discussions offline regarding EFA behavior.
The group concluded the meeting with no additional agenda items.

Jianxin Xiong
Fabric Software
Intel Corporation
Jianxin.xiong at intel.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20260617/7f388df9/attachment-0001.htm>