chenBright commented on code in PR #3569:
URL: https://github.com/apache/brpc/pull/3569#discussion_r4194083583
##########
src/brpc/rdma/rdma_endpoint.cpp:
##########
@@ -1138,7 +1218,8 @@ static ibv_qp* AllocateQp(ibv_cq* send_cq, ibv_cq*
recv_cq, uint32_t sq_size, ui
attr.cap.max_send_sge = GetRdmaMaxSge();
attr.cap.max_recv_sge = 1;
attr.qp_type = IBV_QPT_RC;
- return IbvCreateQp(GetRdmaPd(), &attr);
+ return CreateQpWithInlineData(GetRdmaPd(), &attr, GetRdmaVendorId(),
Review Comment:
Could we cache the successful inline request size from the first QP and use
it as the initial request for subsequent QPs?
With the default 1,024 pre-created QPs, devices that reject the initial size
repeat the same fallback sequence for every QP. For example, an Intel device
limited to 48 bytes would try `216 → 101 → 48` each time. Caching `48` after
the first success would avoid 2,046 failed creation attempts during
initialization.
I suggest:
- Let the first pre-created QP perform the existing negotiation and cache
the **successful request size**.
- Start subsequent QP creations with that cached size.
- Retain the existing `EINVAL` fallback if the cached size is rejected,
since QP configurations may differ.
- Continue reading each QP’s granted capacity from
`attr.cap.max_inline_data` into `RdmaResource`, including the Mellanox 236-byte
cap.
This would reuse the existing initialization path without requiring a
separate probe QP, while preserving compatibility with different QP
configurations
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
