From ed002a427a536096c5c51dc00d2a00ba04a0b068 Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Wed, 26 Jun 2024 14:35:24 -0700 Subject: [PATCH] added sriov blueprint Signed-off-by: Larry Peterson --- dict.txt | 1 + onramp/blueprints.rst | 91 +++++++++++++++++++++++++++++++++++++++++++ onramp/devel.rst | 13 ++++--- 3 files changed, 100 insertions(+), 5 deletions(-) diff --git a/dict.txt b/dict.txt index 9461d05..277a580 100644 --- a/dict.txt +++ b/dict.txt @@ -300,6 +300,7 @@ toolset topo topologies tost +uber udm udp udr diff --git a/onramp/blueprints.rst b/onramp/blueprints.rst index 19a52cc..66143da 100644 --- a/onramp/blueprints.rst +++ b/onramp/blueprints.rst @@ -405,3 +405,94 @@ but revisiting the previous sections—substituting the above for their Aether. Note that the network is configured in exactly the same way for both 4G and 5G. This is because SD-Core's implementation of the UPF is used in both cases. + +Enable SR-IOV and DPDK +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +UPF performance can be improved by enabling SR-IOV and DPDK. This +blueprint supports both optimizations, where the former depends on the +server NIC(s) being SR-IOV capable. The blueprint includes the +following: + +* Global vars file ``vars/main-sriov.yml`` gives the overall blueprint + specification. + +* Inventory file ``hosts.ini`` is identical to that used throughout + this Guide. There are no additional node groups. + +* New make targets, ``5gc-sriov-install`` and ``5gc-sriov-uninstall``, to + be executed along with the standard SD-Core installation. + +* New Ansible role (``sriov``) added to the ``5gc`` + submodule. + +* SRIOV-specific override variables required to configure the core are + included in a new template: + ``deps/5gc/roles/core/templates/sdcore-5g-sriov-values.yaml``. + +* Integration tests require SR-IOV capable servers, and so have not + yet been added to Jenkins. + +To use SR-IOV and DPDK, first copy the vars file to ``main.yml``: + +.. code-block:: + + $ cd vars + $ cp main-sriov.yml main.yml + +You will see the main difference in the ``upf`` block of the ``core`` +section: + +.. code-block:: + + upf: + ip_prefix: "192.168.252.0/24" + iface: "access" + mode: dpdk # Options: af_packet or dpdk + # If mode set to 'dpdk': + # - make sure at least two VF devices are created out of 'data_iface' + # and these devices are attached to vfio-pci driver; + # - use 'sdcore-5g-sriov-values.yaml' file for 'values_file' (above). + +Note the VF device requirement in ``upf`` block comments, and be sure +that the ``core`` block points to the alternative override file: + +.. code-block:: + + values_file: "deps/5gc/roles/core/templates/sdcore-5g-sriov-values.yaml" + + +Guidelines for Blueprints +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Blueprints define alternate "on ramps" for using Aether. They are +intended to provide users with different starting points, depending on +the combination of features they are most interested in. The intent is +also that users eventually "own" their own customized blueprint, for +example by combining features from more than one of the set +distributed with OnRamp. Not all such combinations are valid, and not +all valid combinations have been been tested. This is why there is +not currently one uber-blueprint that satisfies all requirements. + +Users are encourage to contribute new blueprints to the official +release, for example by adding one or more new features/capabilities, +or possibly by demonstrating how to deploy a different combination of +existing features. In addition to meeting the general definition of a +blueprint (as introduced in the introduction to this section), we +recommend the following guidelines. + +* Keep blueprints fairly narrow. One of their main values is to + document (in code) how a particular feature is enabled and + configured. Introduce new roles to keep playbooks narrow. Introduce + new values files to keep each example override file narrow. + +* Use Ansible best-practices for defining playbooks. This means using + Ansible plugins rather than invoking shell scripts, whenever + possible. + +* Minimize the number of variables exposed in + ``vars/main-blueprint.yml``. Their main purpose is direct how + Ansible deploys Aether, and not to configure the individual + subsystems of a given deployment. The latter details are best + defined in a values override file, which can then be referenced by + ``vars/main-blueprint.yml``. diff --git a/onramp/devel.rst b/onramp/devel.rst index 65690ab..63e2c35 100644 --- a/onramp/devel.rst +++ b/onramp/devel.rst @@ -51,14 +51,17 @@ with chart_ref: "/home/ubuntu/aether/sdcore-helm-charts/sdcore-helm-charts" chart_version: 0.13.2 -Note that variable ``core.helm.local_charts`` is a boolean, not the -string ``"true"``. And in this example, we have declared our new chart -to be version ``0.13.2`` instead of ``0.12.8``. +Note that variable ``core.helm.local_charts`` is a boolean, and in +this example, we have declared our new chart to be version ``0.13.2`` +instead of ``0.12.8``. Finally, while there are situations that require modifying full Helm charts, it is also possibly to simply substitute an alternative values -override file for an existing chart by changing the ``core.values_file:`` -variable in ``vars/main.yml``. +override file for an existing chart by changing the +``core.values_file:`` variable in ``vars/main.yml``. (This is a +standard practice when defining new blueprints, as discussed in +:doc:`Other Blueprints `. + Local Container Images ~~~~~~~~~~~~~~~~~~~~~~~~~