UCP/RNDV: Use four read paths on ConnectX-9 XDR#11625
Conversation
|
🤖 Starting review — findings will be posted here when done. |
| int adaptive_progress; | ||
| /** Eager-am multi-lane support */ | ||
| unsigned max_eager_lanes; | ||
| /** Raw configured rendezvous multi-lane limit before auto-resolution; |
There was a problem hiding this comment.
minor: the field can also hold UCS_ULUNITS_INF (rejected in resolve); pls mention it so the comment matches the handled cases.
| if (config->max_rndv_lanes_config == UCS_ULUNITS_AUTO) { | ||
| config->max_rndv_lanes = | ||
| ucp_context_default_max_rndv_lanes(cpu_model); | ||
| } else if ((config->max_rndv_lanes_config == UCS_ULUNITS_INF) || |
There was a problem hiding this comment.
minor: On ILP32 platforms unsigned long is 32-bit, so max_rndv_lanes_config > UINT_MAX can never be true, and a user value equal to 0xFFFFFFFE would alias UCS_ULUNITS_AUTO. This is inherent to ULUNITS semantics and matches other config fields, so it is only worth noting; no change required unless you want to guard the 32-bit case.
evgeny-leksikov
left a comment
There was a problem hiding this comment.
According to description "Vera Rubin systems expose four local XDR devices" I would expect to query NICs and their number but not CPU model. IMO something wrong here.
|
|
||
| The devices to use are selected according to best network speed, PCI bandwidth, | ||
| By default UCX picks the best network devices and splits large messages across | ||
| them. On NVIDIA Vera platforms the default is 4 rails; on all other platforms |
There was a problem hiding this comment.
I would not mention Vera explicitly but rather that the default can be platform specific
|
|
||
| Yes, by setting `UCX_MAX_RNDV_RAILS=<num-rails>`. Currently up to 4 are supported. | ||
| Yes, by setting `UCX_MAX_RNDV_RAILS=<num-rails>`. Up to 4 rails are supported. | ||
| The default is 4 on NVIDIA Vera platforms and 2 on all other platforms. |
| {"MAX_RNDV_RAILS", "auto", | ||
| "Maximal number of devices on which a rendezvous operation may be executed\n" | ||
| "in parallel.\n" | ||
| "The default is 4 on NVIDIA Vera platforms and 2 otherwise.", |
There was a problem hiding this comment.
I am not sure that all Vera CPU platforms will always have 4 HCAs?
|
|
||
| if (config->max_rndv_lanes_config == UCS_ULUNITS_AUTO) { | ||
| config->max_rndv_lanes = | ||
| ucp_context_default_max_rndv_lanes(cpu_model); |
There was a problem hiding this comment.
can we instead add that config in ucx.conf? ideally we would take that information from HCA/GPU topologies rather that from CPU itself?
|
|
||
| if (config->min_rndv_chunk_size == UCS_MEMUNITS_AUTO) { | ||
| config->min_rndv_chunk_size = | ||
| ucp_context_default_min_rndv_chunk_size(cpu_model); |
There was a problem hiding this comment.
same here maybe add min rndv chunk size in ucx.conf under Vera section, this would allow to remove most of the changes here?
| config->max_rndv_lanes = | ||
| ucp_context_default_max_rndv_lanes(cpu_model); | ||
| } else if ((config->max_rndv_lanes_config == UCS_ULUNITS_INF) || | ||
| (config->max_rndv_lanes_config > UINT_MAX)) { |
There was a problem hiding this comment.
The new resolver only rejects values above UINT_MAX, but max_rndv_lanes is subsequently assigned to ucp_proto_multi_init_params_t::max_lanes, whose type is ucp_lane_index_t (uint8_t), and ucp_proto_multi_init asserts it is <= UCP_PROTO_MAX_LANES (64). Consequently 65–255 can abort assertion-enabled builds, while 256 truncates to zero before the assertion and disables the protocol. Please reject values above the actual supported limit during ucp_init and add finite boundary tests.
There was a problem hiding this comment.
(see also svc comment above)
| EXPECT_EQ(2u, ucp_reg_devices_count(e->ucph()->config.ext.max_hca_per_gpu)); | ||
| } | ||
|
|
||
| UCS_TEST_P(test_ucp_context, rndv_platform_defaults) |
There was a problem hiding this comment.
So the Vera auto-resolution is not actually tested in CI?
fbbe131 to
c71cab0
Compare
c71cab0 to
9953434
Compare
9953434 to
0365062
Compare
| UCT_IB_DEVICE_FLAG_DC_V2, 80}, | ||
| {"ConnectX-9", {0x15b3, 4133}, | ||
| UCT_IB_DEVICE_FLAG_MELLANOX | UCT_IB_DEVICE_FLAG_MLX5_PRM | | ||
| UCT_IB_DEVICE_FLAG_DC_V2, 90}, |
There was a problem hiding this comment.
can we extend https://github.com/openucx/ucx/blob/master/config/ucx.conf with hints per NICs in addition to CPU , models?
|
|
||
| dev_spec = uct_ib_device_spec(uct_ib_iface_device(iface)); | ||
| if (uct_ib_iface_port_is_xdr(iface) && | ||
| (dev_spec->flags & UCT_IB_DEVICE_FLAG_XDR_READ_4_PATHS)) { |
There was a problem hiding this comment.
are we sure 4 paths are needed and two are no enough? ideally we would do it on READ side, not sure if it is easy to do..
| if (uct_ib_iface_port_is_xdr(iface) && | ||
| (dev_spec->flags & UCT_IB_DEVICE_FLAG_XDR_READ_4_PATHS)) { | ||
| iface->num_paths = ucs_max(iface->num_paths, | ||
| UCT_IB_XDR_READ_NUM_PATHS); |
There was a problem hiding this comment.
do we need to bounce also the MAX_RMA_RAILS?
Summary
Detect ConnectX-9 XDR interfaces and expose four transport paths for RDMA READ operations.
Rendezvous GET ZCOPY registers both the existing two-path protocol and a four-path protocol, allowing protocol selection to choose by message size. Rendezvous PUT and AM preserve their existing automatic two-path behavior, and explicit lane settings remain authoritative.
Design
Hardware detection uses the ConnectX-9 PCI identifier and XDR link speed rather than the CPU model.
UCX_MAX_RNDV_RAILS=autokeeps a two-device baseline while allowing transports to expose additional read paths on a single device.