Re: [PATCH net 0/3] net/mlx5: Preserve speed and state across vport modify commands
From: Simon Horman
Date: Wed Aug 19 2026 - 10:36:24 EST
On Sun, Aug 16, 2026 at 09:50:12AM +0300, Tariq Toukan wrote:
> Hi,
>
> The firmware vport modify command bundles both admin state and max tx
> speed in a single operation, which requires each side to preserve the
> other field when it only intends to change one.
>
> When modifying max tx speed, the driver already queries the current
> admin state and passes it back to avoid overwriting it. However, this
> query and the subsequent modify were not atomic, a state change
> between the two could cause the modify to overwrite the new state with
> a stale value. The fix holds esw->state_lock across the query-modify
> sequence.
>
> When support for setting max tx speed via the vport modify command was
> introduced, the existing admin state modify path was not updated to
> preserve the current speed. As a result, the firmware interprets the
> zero speed field as an intentional reset. The fix adds a speed query
> before the state modify and passes the result back in the command.
>
> To support that, mlx5_query_vport_max_tx_speed() had to be fixed first:
> it was returning zero whenever the vport was DOWN, which was correct
> for the query_port_speed verb but would defeat the purpose of querying
> before a state modify. The DOWN-to-zero logic is moved to the
> verb-layer caller so the function returns the raw firmware value.
>
> Patch #1 holds esw->state_lock across the state query and modify in
> the speed modify path
> Patch #2 moves the vport DOWN zero mapping to the verb-layer caller
> so the query returns the raw firmware value
> Patch #3 queries current max tx speed before modifying vport state to
> preserve it
For the series:
Reviewed-by: Simon Horman <horms@xxxxxxxxxx>