---
title: "UCX Eager and Rendezvous: When Does the Receiver Have the Payload?"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/ucx-active-message-eager-rendezvous-payload"
last-updated: "2026-10-20"
---

# UCX Eager and Rendezvous: When Does the Receiver Have the Payload?

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

In UCX's active-message API, eager data is available in the arrival callback. Rendezvous can provide a descriptor instead; payload availability in the chosen buffer requires a completed receive. Neither protocol label alone defines the copy path or proves which implementation is faster.

## Locate the decision in UCP

UCX's UCT layer exposes lower-level transport operations, including short, buffered-copy and zero-copy interfaces. UCP builds higher-level protocols from those capabilities and handles transport selection, fragmentation and communication across multiple rails. A UCP protocol choice therefore does not identify one universal hardware primitive.

The question here concerns UCP's active-message API, using UCX v1.19.0 source for its callback and receive semantics. That version identifies the reference being explained; it does not identify the installed or latest release. These API observations should not be assigned to every MPI or NCCL operation merely because a system uses UCX.

References: [UC4](https://openucx.readthedocs.io/en/master/faq.html), [UC1](https://raw.githubusercontent.com/openucx/ucx/v1.19.0/src/ucp/api/ucp_def.h), [UC2](https://raw.githubusercontent.com/openucx/ucx/v1.19.0/src/ucp/api/ucp.h)

## Read the arrival as data or a descriptor

The ucp_am_recv_callback_t callback receives an application header and header_length separately from data and length. In the v1.19.0 definition, the receive parameters identify whether data points to received bytes or an internal UCP descriptor. For rendezvous, length specifies the required receive-buffer size. It is not a count of payload bytes already placed in the application's chosen destination.

The DOCA UCX guide contrasts eager data available during the callback with rendezvous reception into an application-selected buffer. This lets the receiver use message metadata to choose a destination.

References: [UC1](https://raw.githubusercontent.com/openucx/ucx/v1.19.0/src/ucp/api/ucp_def.h), [UC3](https://docs.nvidia.com/doca/sdk/doca-ucx.pdf)

## Identify completion at the selected buffer

UCX v1.19.0 documents ucp_am_recv_data_nbx as a nonblocking receive operation and defines its completion as delivery of the message to the specified buffer. Starting that operation and successfully completing it are different observations. For a rendezvous payload destined for that buffer, the arrival callback alone is insufficient evidence of completed placement.

Eager availability during a callback also leaves a separate question: is the callback's data location the destination the application ultimately needs? A statement that the receiver has the data should identify the location as well as the event.

Application processing and durability remain separate questions, covered by the related RDMA-completion article.

References: [UC2](https://raw.githubusercontent.com/openucx/ucx/v1.19.0/src/ucp/api/ucp.h), [UC3](https://docs.nvidia.com/doca/sdk/doca-ucx.pdf)

## Follow a hypothetical 32-byte header and 1 MiB payload

Consider a wholly hypothetical, supported active message containing 32 application-header bytes and a contiguous 1 MiB payload. Stipulate that these sizes and a complete-message callback are supported for this example. The header identifies object X, whose selected destination is buffer B. These premises establish neither a universally permitted header size nor an actual UCX configuration.

One MiB equals 1,048,576 bytes. The application header plus payload therefore totals 32 + 1,048,576 = 1,048,608 application bytes. The separate payload length remains 1,048,576 bytes; adding the header does not enlarge the payload.

Explicitly choose rendezvous for the first case. At the arrival notification, the receiver has the 32-byte header and a descriptor, while the callback's length describes 1,048,576 payload bytes. Stipulate that the payload receive into B has not yet begun. B does not yet contain this payload. The receiver knows the required amount and where object X should go, without having completed that placement.

Now stipulate successful completion of the receive into B. The payload is delivered there. This later event concerns the same 1,048,576-byte object; it does not add another payload to the application's message total or establish how many internal copies occurred.

In a separately stipulated supported eager case for the same content and complete-message callback, the payload is available in the callback. Its presence there does not establish placement in B.

The protocol choices are explicit premises, not a rule that 1 MiB always selects rendezvous. The arithmetic counts application bytes only. It supplies no wire-overhead total, traffic observation, elapsed time or throughput result.

References: [UC1](https://raw.githubusercontent.com/openucx/ucx/v1.19.0/src/ucp/api/ucp_def.h), [UC2](https://raw.githubusercontent.com/openucx/ucx/v1.19.0/src/ucp/api/ucp.h), [UC3](https://docs.nvidia.com/doca/sdk/doca-ucx.pdf)

## Compare placement control and coordination

Rendezvous offers destination selection through an additional receive operation. Eager offers data during its callback. The useful tradeoff is receiver placement control versus that coordination; neither behavior establishes a speed advantage.

Placement and copying answer different questions. Placement asks whether the payload has reached the buffer under discussion. The copy path describes how bytes move along the implementation's route. UCX's official FAQ includes sample labels for eager zero-copy and a rendezvous pipeline involving cuda_copy. Eager is not synonymous with a fully copied path, and rendezvous is not synonymous with an entirely copy-free path. They are tagged-send examples, not measurements of the active-message case above; their historical byte ranges are not defaults for another system.

Assess the actual memory types, supported path, software build and selected protocol. An eager or rendezvous label alone cannot establish a GPU-direct path. The related GPU-to-NIC topology article addresses the separate attachment and platform-support question.

References: [UC2](https://raw.githubusercontent.com/openucx/ucx/v1.19.0/src/ucp/api/ucp.h), [UC3](https://docs.nvidia.com/doca/sdk/doca-ucx.pdf), [UC4](https://openucx.readthedocs.io/en/master/faq.html)

## Compare offers at the same receiver state

A useful supplier explanation identifies the message form, the intended destination and the event that makes its payload ready there. Ask whether an arrival record means that bytes were exposed in a callback, that a descriptor was supplied, or that a receive into the intended buffer completed. An unexplained received label leaves the central distinction unresolved.

This also changes how to read a performance comparison. Timing one implementation until eager data is available and another only until its rendezvous descriptor arrives ends the clocks at different receiver states. Before ranking the results, establish a common useful endpoint and comparable work. The hypothetical example contains no timing evidence, so neither case wins a speed comparison.

The purchasing conclusion should connect the application's placement requirement to the supplied implementation and its evidence. A protocol name by itself cannot make that connection.

## Carry physical connection requirements into the cabling scope

If the selected cluster needs physical connections installed or documented, use the related structured-cabling service and project inquiry to discuss agreed fiber and copper installation, labels, connection records and physical checks. Bring a nonconfidential endpoint and route plan, specified assemblies, the appointed materials supplier and required handoff records.

UCX integration, protocol selection and application validation belong with the appointed software and network specialists. This article explains a runtime distinction for evaluating a proposal; physical work needs its own agreed scope and authorization.

References: [L1](https://www.leviathansystems.co/services/structured-cabling)

## Primary sources

- [UC1 — OpenUCX v1.19.0: active-message callback definition](https://raw.githubusercontent.com/openucx/ucx/v1.19.0/src/ucp/api/ucp_def.h). Checked 2026-10-20. Defines the callback's separate header, data and length arguments, including rendezvous descriptor and required-buffer-size semantics.
- [UC2 — OpenUCX v1.19.0: active-message receive API](https://raw.githubusercontent.com/openucx/ucx/v1.19.0/src/ucp/api/ucp.h). Checked 2026-10-20. Identifies rendezvous arrivals and defines receive completion at the specified buffer. Header-size support remains implementation-specific.
- [UC3 — NVIDIA DOCA UCX: active-message communication](https://docs.nvidia.com/doca/sdk/doca-ucx.pdf). Checked 2026-10-20. Mechanism explanation for eager arrival and rendezvous destination selection; actual protocol performance requires implementation-specific evidence.
- [UC4 — OpenUCX FAQ: UCP, UCT and protocol examples](https://openucx.readthedocs.io/en/master/faq.html). Checked 2026-10-20. Layer definitions and illustrative tagged-send protocol labels. Example ranges do not establish current selection thresholds.
- [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Agreed physical installation and connection records provide the service context; software and network-fabric configuration have separate responsibilities.

## Related Leviathan resources

- [RDMA completion, application processing and durability](/articles/rdma-write-completion-versus-application-durability)
- [GPU-to-NIC topology and GPUDirect RDMA support](/articles/gpu-server-pcie-topology-gpudirect-rdma)
- [Read NCCL algbw and busbw at their actual scope](/articles/nccl-bandwidth-validation)
- [Structured cabling and physical connection records](/services/structured-cabling)
- [Discuss a physical cabling project](/contact?service=structured-cabling&from=%2Farticles%2Fucx-active-message-eager-rendezvous-payload)

## Discuss the physical cabling package

Share approved endpoints and routes, specified assemblies, supply responsibilities and required records to discuss installation scope and availability.

[Discuss the scope](/contact?service=structured-cabling&from=/articles/ucx-active-message-eager-rendezvous-payload)