Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-43683

Document SR-IOV Operator behavior upon external changes to VF MTU

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • 4.14.z, 4.15.z, 4.17.z, 4.16.z, 4.18.0
    • Documentation / CNF
    • Moderate
    • None
    • False
    • Hide

      None

      Show
      None

      Document that SR-IOV VFs included in SriovNetworkNodePolicy CRs are fully managed by the SR-IOV Network Operator, with the exception when `externallyManaged: true` is set.

      As a consequence, users must not alter any VF configuration when VFs are in the root network namespace, i.e. not attached to Pods. Should users change anything, the expectation is that the SR-IOV Network Operator may reconcile (i.e. undo/revert) to the defined configuration in the SriovNetworkNodePolicy.

      For example, a SriovNetworkNodePolicy is created and defines a VF partitioning with `pfNames: "netpf0#2-7"` and with `mtu: 9800`. A user changes the MTU value of any of VFs 2 to 7 in the root network namespace to a different MTU value. The SR-IOV Network Operator will detect an undesired MTU value and set MTU 9800 per the policy. As of today (Oct 22, 2024) the reconciliation logic in the SR-IOV Network Operator will trigger a node drain (reboot) which can impact workloads (SR-IOV and non-SRIOV workloads). 
      In order to inhibit the MTU reconciling process, the field `SriovNetworkNodePolicy.Spec.Mtu` field must be left blank.

      Version-Release number of selected component (if applicable):

          4.14+ (4.12 and 4.13 will soon reach end of life)

       

              rhn-support-tradej Tomas 'Sheldon' Radej
              carlosgoncalves Carlos Goncalves
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: