Re: [PATCH RFC 2/3] RDMA/srp: Post command IUs inline

[Bart Van Assche]

On 10/15/26 5:51 AM, Andrei-Alexandru Bleortu wrote:
> +/*
> + * The verbs API cannot report a device's inline data limit. Some drivers
> + * have a fixed one: Intel irdma 216, 101 or 48 depending on the
> + * generation, Alibaba erdma 96. Try those first, by vendor ID, then step
> + * down SRP_INLINE_STEP bytes at a time to zero. libfabric's verbs
> + * provider also probes the limit (vrb_find_max_inline()).
> + */
> +static const struct {
> +	u32	vendor_id;
> +	u32	max_inline;
> +} srp_inline_limits[] = {
> +	{ PCI_VENDOR_ID_INTEL, 216 },
> +	{ PCI_VENDOR_ID_INTEL, 101 },
> +	{ PCI_VENDOR_ID_INTEL, 48 },
> +	{ PCI_VENDOR_ID_ALIBABA, 96 },
> +};

A table like the above makes maintenance of the RDMA subsystem harder
than necessary. Shouldn't a mechanism be added for querying this
information from the RDMA adapter?

> +	 * Ask for enough inline data to post command IUs inline (see
> +	 * srp_post_send()), or for as much as the device accepts.
> +	 */
> +	cap = init_attr->cap;
> +	inline_size = srp_inline_size(attr->vendor_id, SRP_MAX_INLINE_DATA,
> +				      false);
> +	for (;;) {
> +		init_attr->cap = cap;
> +		init_attr->cap.max_inline_data = inline_size;
> +		ret = srp_create_qp(ch, init_attr, &qp);
> +		if (!ret || !inline_size)
> +			break;
> +		inline_size = srp_inline_size(attr->vendor_id, inline_size,
> +					      true);
>   	}

What changes in the RDMA core would be needed to eliminate this loop?

Thanks,

Bart.