Re: [PATCH net V2] net/mlx5: Lag, split aggregate speed into oper and max helpers

[Or Har-Toov <ohartoov@nvidia.com>]

On 30/09/2026 20:08, netdev-bot+sinfo@kernel.org wrote:
> External email: Use caution opening links or attachments
> 
> 
> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>   - How the issue was discovered, e.g. hit in production, hit during
>     development, syzbot report, manual code inspection, LLM or static
>     analysis tool scan.
> 
>   - Whether the issue was actually triggered, or is only theoretical
>     (e.g. found by code inspection). If it was triggered please include
>     the symptoms, like the stack trace or error messages.
> 
>   - What hardware the change was tested on. For driver fixes please
>     mention the device (and if relevant firmware version) used for
>     testing, or say that the change was not tested on real hardware.
> 
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
> 
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

The bugs were discovered during integration and reproduced on a 
back-to-back ConnectX-8 setup.

The first bug (stale oper speed when link goes down) was observed: after 
the link partner disconnected, the aggregate TX speed reported to vports 
remained full speed because firmware still returned the last oper speed, 
causing vports to be rate-limited to the old aggregate speed.

The second bug (active-backup summing all port speeds instead of the 
active port's speed) was also triggered: in active-backup mode the 
computed aggregate was double the expected value since both port speeds 
were summed even though only one port was active.