Re: [PATCH net-next] net/mlx5: SD, prefer sd_group_size from vport context

On 11/08/2026 15:44, Simon Horman wrote:
> External email: Use caution opening links or attachments
> 
> 
> On Mon, Aug 10, 2026 at 12:30:37PM +0300, Tariq Toukan wrote:
>> From: Shay Drory <[email protected]>
>>
>> Newer FW reports the SD group size directly in the NIC vport context
>> via the sd_group_size field, gated by the sd_group_size capability.
>> Switch sd_init() to source the group size from there and fall back to
>> the MPIR-based host_buses query only when the cap is absent.
>> sd_group_size might return 1 in some FW configuration. Add explicit
>> check to disable SD creation in this case.
>>
>> While here, rename host_buses to group_size throughout sd.c to follow
>> the new name on capable FW.
>>
>> issue: 4680618
>> Signed-off-by: Shay Drory <[email protected]>
>> Reviewed-by: Moshe Shemesh <[email protected]>
>> Signed-off-by: Tariq Toukan <[email protected]>
> 
> Hi,
> 
> I'd appreciate it if you could take a look over the AI-generated review
> of this patch at https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260810093037.3138197-1-tariqt%40nvidia.com
> 
> But my feeling is that this patch is good as-is.
> 
> Reviewed-by: Simon Horman <[email protected]>

Hi,

thanks for the review.

Regarding the comment:
"Can an MPIR-derived group_size of 0 or 1 therefore still reach
sd->group_size?"

[SD] AFAIK, no.
MPIR can't be 1, and if sdm bit is set, it means group_size != 0.


Regarding the comment:
"Would it be clearer to always write a defined value in the callee, or 
to report capability validity explicitly (for example a bool *valid), or
to have sd.c test MLX5_CAP_GEN(dev, sd_group_size) directly instead of
overloading a representable field encoding?

[SD] We considered it, and prefer keeping the cap check confined to
mlx5_query_nic_vport_sd_group() so callers don't have to repeat it.