• OVS Hardware offload
    • False
    • False
    • Done
    • OCPPLAN-6495 - ShiftonStack Enable Telco/NFV 5G core and edge/RAN
    • Impediment
    • 0% To Do, 0% In Progress, 100% Done
    • Undefined

      Background

      Containerized Network Functions (CNFs) are the evolution of network functions in the Cloud and very often are deployed on the same hardware that is already used for the Virtualized network Functions (VNFs).

      In OpenShift 4.8, we started to support features for SR-IOV and DPDK, by allowing the users to add additional networks to the workers and create Neutron ports with direct type.

      In 4.9, we will enable more advanced use-cases, like Hardware offload, which brings two benefits:

      • Provide greater throughput
      • Increase CPU core efficiency and scalability

      Goals

      • (IPI) Implement the missing features in the installer and its dependencies (e.g. CAPO) to properly configure the Neutron ports
      • Enable developers to test the feature with a minimal viable environment
      • Define a Testing Strategy for OVS TC Flower Offload
      • Document how to use the feature and optionally provide UPI examples.
      • Run benchmark and validate the results

      Summary

      OVS Hardware offload is part of the technologies offered by SR-IOV and most of the work is done by the system tools, OpenStack and the SRIOV network operator. Some integration, testing and document has to happen on our side to enable our customers to use that feature in production.

      Definition of Done

      • Feature is complete (code + doc + tests)
      • Developers can reproduce an environment with OVS Hardware offload and test the feature while developing it
      • QE has a testing strategy and can successfully run the tests on time for OCP 4.9
      • The feature is documented.
      • Blog post

      Notes from planning

      • Most of the configuration happens in OpenStack
      • QE has all the needed hardware (via the new Telco lab). Hardware needs to be configured to test any of the NFV scenarios.
      • QE's lab needs to add support for Mellanox (25G nics) - on TRex, we have Intel 10G (for traffic generation)
      • QE has no CI jobs yet, and still working on the new Telco lab. Automation is in progress.
      • QE will do performance testing
      • UPI is the target now (and what's tested by QE)
      • Write a blog post

            [OSASINFRA-2804] Enable OVS Hardware offload - GA

            Everything was tested on 4.11 and zgreenbe@redhat.com is now reviewing the doc.

            Emilien Macchi added a comment - Everything was tested on 4.11 and zgreenbe@redhat.com is now reviewing the doc.

            Max Bridges added a comment -

            Will this make it for 4.11? It seems like the software changes aren't QEed yet, nor are the docs. emacchi@redhat.com zgreenbe@redhat.com 

            Max Bridges added a comment - Will this make it for 4.11? It seems like the software changes aren't QEed yet, nor are the docs. emacchi@redhat.com zgreenbe@redhat.com  

            zgreenbe@redhat.com who is working on its verification is currently on PTO. However he's helping us to deploy an environment so other teams (CNF compute mainly) to take a look to see what's going wrong.
            Note that the issue that we encountered is not OpenStack specific and it's likely an issue for all platforms, and not in one of our components. So I really want to avoid blocking the feature to be delivered in 4.11 because of this bug, since we probably have a workaround.

            I would like to keep it for 4.11 if that's possible.

            Emilien Macchi added a comment - zgreenbe@redhat.com who is working on its verification is currently on PTO. However he's helping us to deploy an environment so other teams (CNF compute mainly) to take a look to see what's going wrong. Note that the issue that we encountered is not OpenStack specific and it's likely an issue for all platforms, and not in one of our components. So I really want to avoid blocking the feature to be delivered in 4.11 because of this bug, since we probably have a workaround. I would like to keep it for 4.11 if that's possible.

            Since QE testing is blocked by 

             

             and final RC target is 21-July, should the fixVersion change to something other than 4.11?   juriarte@redhat.com zgreenbe@redhat.com emacchi@redhat.com rhn-support-mdineen 

            Mike Fiedler added a comment - Since QE testing is blocked by    https://bugzilla.redhat.com/show_bug.cgi?id=2099546 https://bugzilla.redhat.com/show_bug.cgi?id=2099547  and final RC target is 21-July, should the fixVersion change to something other than 4.11?   juriarte@redhat.com zgreenbe@redhat.com emacchi@redhat.com rhn-support-mdineen  

            Not all trackers are closed! They must be reviewed and closed before this can ship!

            OpenShift Jira Bot added a comment - Not all trackers are closed! They must be reviewed and closed before this can ship!

              emacchi@redhat.com Emilien Macchi
              mdemaced Maysa De Macedo Souza
              Ziv Greenberg Ziv Greenberg
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: