Skip to content

rdma/mlx5_dv: stamp RoCE IPv4 TOS from nvme/nvmf transport opts - #7

Merged
jleeh merged 1 commit into
rebase/v26.05from
fix/mlx5-dv-roce-tos-from-transport
Aug 28, 2026
Merged

rdma/mlx5_dv: stamp RoCE IPv4 TOS from nvme/nvmf transport opts#7
jleeh merged 1 commit into
rebase/v26.05from
fix/mlx5-dv-roce-tos-from-transport

Conversation

@jleeh

@jleeh jleeh commented Aug 28, 2026

Copy link
Copy Markdown

Summary

  • Stop hardcoding TOS 96 / SL 3 on mlx5_dv RTR.
  • Copy transport_tos (initiator) and nvmf tos (target) onto the provider QP, then into the RTR AV: traffic_class = tos, sl = tos >> 5.
  • TOS 0 leaves the AV untagged (rdma-core default).
  • MA keeps CS3 while dataEngineRdmaPriorityClass is v2: 3 (TOS 96). Changing that setting will now change the wire mark after QP reconnect.

Test plan

  • Build with --with-rdma=mlx5_dv; pin and IM reset.15
  • Canary ma5-11: IM logs RoCE RTR TOS 96; xe-1/1/5 Q3 still increments
  • With tos/transport_tos 0, Q3 does not get new writes

Made with Cursor

Hardcoding TOS 96 made the canary work but ignored
dataEngineRdmaPriorityClass. Copy transport_tos / nvmf tos onto the
provider QP and into the RTR AV (tclass=tos, sl=tos>>5). TOS 0 leaves
the AV untagged.

Co-authored-by: Cursor <cursoragent@cursor.com>
@jleeh
jleeh merged commit adb9232 into rebase/v26.05 Aug 28, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant