UCT/IB: Fix RoCE LAG put bandwidth estimate - #11691
Conversation
54a47f5 to
8b04ca4
Compare
42b0d01 to
22a708c
Compare
|
🤖 Starting review — findings will be posted here when done. |
| if (uct_ib_iface_is_roce(iface)) { | ||
| /* RoCE - number of paths is RoCE LAG level */ | ||
| iface->num_paths = uct_ib_iface_roce_lag_level(iface); | ||
| if (uct_ib_iface_port_is_xdr(iface)) { |
There was a problem hiding this comment.
if (uct_ib_iface_port_active_speed(iface) > UCT_IB_SPEED_NDR)
or => UCT_IB_SPEED_XDR ?
There was a problem hiding this comment.
XDR detection is different than NDR so we cannot merge them to the same function and use it here
|
🤖 Starting review — findings will be posted here when done. |
|
Test coverage note: the changed logic ( |
0ba6e1a to
2667a53
Compare
2667a53 to
8d51df3
Compare
|
🤖 Starting review — findings will be posted here when done. |
|
@iyastreb can review? |
|
I'm not comfortable with this statement:
I thought a single RoCE LAG QP/path transmits through one physical port. Full LAG bandwidth requires multiple QPs/paths. Or I miss something? |
| /* RoCE - number of paths is RoCE LAG level */ | ||
| iface->num_paths = uct_ib_iface_roce_lag_level(iface); | ||
| if (uct_ib_iface_port_is_xdr(iface)) { | ||
| iface->num_paths = UCT_IB_HIGH_SPEED_NUM_PATHS; |
There was a problem hiding this comment.
So here we essentially reduce the number of possible paths, but why?
There was a problem hiding this comment.
because number of required paths for full BW is reduced on XDR
There was a problem hiding this comment.
but what if it is a LAG consisting of, say 3 devices?
| if (uct_ib_iface_is_roce(iface) && | ||
| (uct_ib_iface_roce_lag_level(iface) > 1)) { | ||
| if (uct_ep_op_is_get(op) && uct_ib_iface_port_is_xdr(iface)) { | ||
| max_path_bandwidth = UCT_IB_XDR_READ_PATH_BANDWIDTH; |
There was a problem hiding this comment.
But this also modifies non-RoCE code..
There was a problem hiding this comment.
actually it doesn't because it's just lines reorder (last "else" case moved to the top)
There was a problem hiding this comment.
why is this change needed?
imo it is harder to read now
CX8 has four planes per port, and DDP allows a single QP/WQE to spray packets across all planes. RDMA WRITE payload is placed immediately, whereas RDMA READ requires responder execution and response generation. PUT is a streaming, packet-sprayed operation; GET is a request/response operation bounded by the per-QP read-credit window. On XDR that window is 16, so four QPs recreate 64-way concurrency. https://nvidia.atlassian.net/wiki/spaces/SW/pages/2899157185/DDP+-+Direct+Data+Placement |
brminich
left a comment
There was a problem hiding this comment.
did you run some basic perf tests (osu?) with XDR and NDR
| /* RoCE - number of paths is RoCE LAG level */ | ||
| iface->num_paths = uct_ib_iface_roce_lag_level(iface); | ||
| if (uct_ib_iface_port_is_xdr(iface)) { | ||
| iface->num_paths = UCT_IB_HIGH_SPEED_NUM_PATHS; |
There was a problem hiding this comment.
but what if it is a LAG consisting of, say 3 devices?
| if (uct_ib_iface_is_roce(iface) && | ||
| (uct_ib_iface_roce_lag_level(iface) > 1)) { | ||
| if (uct_ep_op_is_get(op) && uct_ib_iface_port_is_xdr(iface)) { | ||
| max_path_bandwidth = UCT_IB_XDR_READ_PATH_BANDWIDTH; |
There was a problem hiding this comment.
why is this change needed?
imo it is harder to read now
| uint32_t active_speed = uct_ib_iface_port_active_speed(iface); | ||
| uint8_t active_width = uct_ib_iface_is_roce(iface) ? | ||
| uct_ib_iface_port_active_width(iface) : 1; | ||
|
|
||
| return (active_width * active_speed) == UCT_IB_SPEED_XDR; |
What?
Why?
PUT operations can use the full RoCE LAG bandwidth, so dividing the estimate by dev_num_paths makes the protocol selection logic underrate PUT relative to GET.
Impact
This fixes bandwidth estimation for RoCE LAG PUT operations without changing the existing GET/NDR/XDR read bandwidth limits.