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

[Shay Drori]

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 <shayd@xxxxxxxxxx>
> >
> > 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 <shayd@xxxxxxxxxx>
> > Reviewed-by: Moshe Shemesh <moshe@xxxxxxxxxx>
> > Signed-off-by: Tariq Toukan <tariqt@xxxxxxxxxx>
>
> 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 <horms@xxxxxxxxxx>

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.