Missing validation for SR-IOV VF MTU exceeding parent PF MTU

[kanlkan]

Description:

MTU can be configured via opaque.parameters.interface.mtu.
However, for SR-IOV VFs, it is currently possible to set an MTU larger than the parent PF’s MTU due to the lack of validation.

This can lead to inconsistent or invalid configurations.
It would be better to introduce validation to prevent this. Possible approaches include:

1. Logging a warning and falling back to the PF’s MTU
2. Logging an error and rejecting pod creation
3. Logging only (no enforcement)

Environment:

• Kubernetes: v1.35.3
• containerd: v2.2.2
• runc: v1.4.2
• RDMA NIC: Mellanox ConnectX-6

[kanlkan]

I’ve prepared a sample implementation based on option 1 (fallback to the PF’s MTU):
https://github.com/kanlkan/dranet/tree/fix/vf-mtu

However, considering Kubernetes conventions, automatic fallback may not be the best approach.
I’d like to get your thoughts on this.

[aojea]

IMHO an Invalid option should fail, the way I think about it is: someone makes a decision to set field Y to X, if X is invalid the system should tell the person that value is invalid, if it changes the value the person will carrying with the error without knowing it

[kanlkan]

@aojea

IMHO an Invalid option should fail, the way I think about it is: someone makes a decision to set field Y to X, if X is invalid the system should tell the person that value is invalid, if it changes the value the person will carrying with the error without knowing it

Thank you for the feedback. I agree with your point.
If you think this direction makes sense, I’d be happy to open a PR implementing the “log an error and reject pod creation” option.

[aojea]

please go ahead @kanlkan

[gauravkghildiyal]

/assign @kanlkan