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

SRIOV: Intel E810: Creating a pod takes up to 2 minutes.

XMLWordPrintable

    • +
    • Important
    • None
    • CNF Network Sprint 231, CNF Network Sprint 232, CNF Network Sprint 233, CNF Network Sprint 234, CNF Network Sprint 235, CNF Network Sprint 236, CNF Network Sprint 237, CNF Network Sprint 238, CNF Network Sprint 239
    • 9
    • Rejected
    • False
    • Hide

      None

      Show
      None
    • Hide
      * Previously, for Intel E810 NICs, resetting a MAC address on an SR-IOV with a virtual function (VF) when a pod was deleted caused a failure. This resulted in a long delay when creating a pod with SR-IOV VF. With this update, the container network interface (CNI) does not fail fixing this issue. (link:https://issues.redhat.com/browse/OCPBUGS-5892[*OCPBUGS-5892*])

      Cause: Resetting a MAC address on an SR-IOV VF upon Pod deletion may fail for Intel E810 NICs.
      Consequence: Creating a Pod with SR-IOV VF may take up to 2 minutes on Intel E810 NIC cards.
      Fix: drivers have async mac allocation or get a device or resouce busy errors until the vf device is fully configured on the system so we wait a few ms
      Result: after retrying, the allocation will succeed and the CNI will not fail (which would otherwise cause the long delay)
      Show
      * Previously, for Intel E810 NICs, resetting a MAC address on an SR-IOV with a virtual function (VF) when a pod was deleted caused a failure. This resulted in a long delay when creating a pod with SR-IOV VF. With this update, the container network interface (CNI) does not fail fixing this issue. (link: https://issues.redhat.com/browse/OCPBUGS-5892 [* OCPBUGS-5892 *]) Cause: Resetting a MAC address on an SR-IOV VF upon Pod deletion may fail for Intel E810 NICs. Consequence: Creating a Pod with SR-IOV VF may take up to 2 minutes on Intel E810 NIC cards. Fix: drivers have async mac allocation or get a device or resouce busy errors until the vf device is fully configured on the system so we wait a few ms Result: after retrying, the allocation will succeed and the CNI will not fail (which would otherwise cause the long delay)
    • Bug Fix
    • Done
    • 7/13: merged in 4.14 working on backports

      Description of problem:

      Creating a pod with vf takes up to 2 minutes.

  Warning  FailedCreatePodSandBox  4s                kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_testpod-br2rg_sriov-operator-tests_cd1295e2-bc1f-46a9-b5fb-538c94ed2e48_0(de9ffb0385fd56d085434588f03d24f756e5f5bbae0f8b3b0d522f1ee1483b59): error adding pod sriov-operator-tests_testpod-br2rg to CNI network "multus-cni-network": plugin type="multus" name="multus-cni-network" failed (add): [sriov-operator-tests/testpod-br2rg/cd1295e2-bc1f-46a9-b5fb-538c94ed2e48:test-sriov-static-usual]: error adding container to network "test-sriov-static-usual": SRIOV-CNI failed to load netconf: LoadConf(): the VF 0000:86:01.0 does not have a interface name or a dpdk driver

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

      Intel nic E810
4.12.0-rc.8
sriov-network-operator.v4.12.0-202301062016

      How reproducible:

      25%

      Steps to Reproduce:

      1.Create sriov network policies with 64 VF
2.Create a pod with 1 VF
3.Delete the pod
4.Create the pod again

      Actual results:

      Creating a pod with vf takes up to 2 minutes.

      Expected results:

      Creating a pod with vf takes up to 10 sec.

      Additional info:

      There is no the issue on e710 and metllanox nics

              sscheink@redhat.com Sebastian Scheinkman
              rhn-cnf-elevin Evgeny Levin
              Evgeny Levin Evgeny Levin
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: