Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

23.10. Utilisation de DPDK et RDMA

download PDF

L'application conteneurisée Data Plane Development Kit (DPDK) est prise en charge sur OpenShift Container Platform. Vous pouvez utiliser du matériel réseau de virtualisation d'E/S à racine unique (SR-IOV) avec le kit de développement du plan de données (DPDK) et avec l'accès direct à la mémoire à distance (RDMA).

Pour plus d'informations sur les appareils pris en charge, reportez-vous à la section Appareils pris en charge.

23.10.1. Utilisation d'une fonction virtuelle en mode DPDK avec un NIC Intel

Conditions préalables

  • Installez le CLI OpenShift (oc).
  • Installer l'opérateur de réseau SR-IOV.
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Créez l'objet SriovNetworkNodePolicy suivant, puis enregistrez le YAML dans le fichier intel-dpdk-node-policy.yaml. 

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: intelnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "8086"
    deviceID: "158b"
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: vfio-pci 1
    1
    Spécifiez le type de pilote pour les fonctions virtuelles à vfio-pci.
    Note

    Voir la section Configuring SR-IOV network devices pour une explication détaillée de chaque option de SriovNetworkNodePolicy.

    Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger les nœuds et, dans certains cas, les redémarrer. L'application d'une modification de configuration peut prendre plusieurs minutes. Assurez-vous au préalable qu'il y a suffisamment de nœuds disponibles dans votre cluster pour gérer la charge de travail expulsée.

    Après l'application de la mise à jour de la configuration, tous les pods de l'espace de noms openshift-sriov-network-operator passeront à l'état Running.

  2. Créez l'objet SriovNetworkNodePolicy en exécutant la commande suivante : 

    $ oc create -f intel-dpdk-node-policy.yaml

  3. Créez l'objet SriovNetwork suivant, puis enregistrez le YAML dans le fichier intel-dpdk-network.yaml. 

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: intel-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |-
# ... 1
  vlan: <vlan>
  resourceName: intelnics
    1
    Spécifier un objet de configuration pour le plugin CNI ipam sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition des pièces jointes.
    Note

    Voir la section "Configuration du réseau supplémentaire SR-IOV" pour une explication détaillée de chaque option sur SriovNetwork.

    Une bibliothèque optionnelle, app-netutil, fournit plusieurs méthodes API pour collecter des informations réseau sur le pod parent d'un conteneur.

  4. Créez l'objet SriovNetwork en exécutant la commande suivante : 

    $ oc create -f intel-dpdk-network.yaml

  5. Créez la spécification Pod suivante, puis enregistrez le YAML dans le fichier intel-dpdk-pod.yaml. 

    apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 1
  annotations:
    k8s.v1.cni.cncf.io/networks: intel-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 2
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3
    volumeMounts:
    - mountPath: /dev/hugepages 4
      name: hugepage
    resources:
      limits:
        openshift.io/intelnics: "1" 5
        memory: "1Gi"
        cpu: "4" 6
        hugepages-1Gi: "4Gi" 7
      requests:
        openshift.io/intelnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
    1
    Spécifiez le même target_namespace où l'objet SriovNetwork intel-dpdk-network est créé. Si vous souhaitez créer le pod dans un espace de noms différent, modifiez target_namespace à la fois dans la spécification Pod et dans l'objet SriovNetowrk.
    2
    Spécifiez l'image DPDK qui inclut votre application et la bibliothèque DPDK utilisée par l'application.
    3
    Spécifier les capacités supplémentaires requises par l'application à l'intérieur du conteneur pour l'allocation de pages énormes, l'allocation de ressources système et l'accès à l'interface réseau.
    4
    Monter un volume hugepage sur le pod DPDK sous /dev/hugepages. Le volume hugepage est soutenu par le type de volume emptyDir, le support étant Hugepages.
    5
    Facultatif : Spécifiez le nombre de dispositifs DPDK alloués au pod DPDK. Cette demande de ressource et cette limite, si elles ne sont pas explicitement spécifiées, seront automatiquement ajoutées par l'injecteur de ressources du réseau SR-IOV. L'injecteur de ressources réseau SR-IOV est un composant du contrôleur d'admission géré par l'opérateur SR-IOV. Il est activé par défaut et peut être désactivé en définissant l'option enableInjector sur false dans le CR SriovOperatorConfig par défaut.
    6
    Spécifiez le nombre d'unités centrales. Le pod DPDK nécessite généralement que des CPU exclusifs soient alloués par le kubelet. Pour ce faire, définissez la politique du gestionnaire de CPU sur static et créez un pod avec Guaranteed QoS.
    7
    Spécifiez la taille de la page d'accueil hugepages-1Gi ou hugepages-2Mi et la quantité de pages d'accueil qui seront allouées au module DPDK. Configurez 2Mi et 1Gi hugepages séparément. La configuration de la page d'accueil 1Gi nécessite l'ajout d'arguments de noyau aux nœuds. Par exemple, l'ajout des arguments du noyau default_hugepagesz=1GB, hugepagesz=1G et hugepages=16 aura pour effet d'allouer 16*1Gi hugepages lors du démarrage du système.

  6. Créez le module DPDK en exécutant la commande suivante : 

    $ oc create -f intel-dpdk-pod.yaml

23.10.2. Utilisation d'une fonction virtuelle en mode DPDK avec un NIC Mellanox

Vous pouvez créer une stratégie de nœud de réseau et créer un pod Data Plane Development Kit (DPDK) à l'aide d'une fonction virtuelle en mode DPDK avec un NIC Mellanox.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous avez installé l'opérateur de réseau SR-IOV (Single Root I/O Virtualization).
  • Vous vous êtes connecté en tant qu'utilisateur avec les privilèges cluster-admin.

Procédure

  1. SriovNetworkNodePolicy Enregistrez la configuration YAML suivante dans un fichier mlx-dpdk-node-policy.yaml: 

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 1
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 2
  isRdma: true 3
    1
    Indiquez le code hexadécimal du périphérique du réseau SR-IOV.
    2
    Spécifiez le type de pilote pour les fonctions virtuelles à netdevice. Une fonction virtuelle (VF) Mellanox SR-IOV peut fonctionner en mode DPDK sans utiliser le type de périphérique vfio-pci. Le périphérique VF apparaît comme une interface réseau du noyau à l'intérieur d'un conteneur.
    3
    Activer le mode RDMA (Remote Direct Memory Access). Ceci est nécessaire pour que les cartes Mellanox fonctionnent en mode DPDK.
    Note

    Voir Configuring an SR-IOV network device pour une explication détaillée de chaque option de l'objet SriovNetworkNodePolicy.

    Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger les nœuds et, dans certains cas, les redémarrer. L'application d'une modification de configuration peut prendre plusieurs minutes. Assurez-vous au préalable qu'il y a suffisamment de nœuds disponibles dans votre cluster pour gérer la charge de travail expulsée.

    Après l'application de la mise à jour de la configuration, tous les pods de l'espace de noms openshift-sriov-network-operator passeront à l'état Running.

  2. Créez l'objet SriovNetworkNodePolicy en exécutant la commande suivante : 

    $ oc create -f mlx-dpdk-node-policy.yaml

  3. SriovNetwork Enregistrez la configuration YAML suivante dans un fichier mlx-dpdk-network.yaml: 

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 1
...
  vlan: <vlan>
  resourceName: mlxnics
    1
    Spécifier un objet de configuration pour le plugin IPAM (gestion des adresses IP) Container Network Interface (CNI) sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition de l'attachement.
    Note

    Voir Configuring an SR-IOV network device pour une explication détaillée de chaque option de l'objet SriovNetwork.

    La bibliothèque d'options app-netutil fournit plusieurs méthodes API pour collecter des informations réseau sur le module parent d'un conteneur.

  4. Créez l'objet SriovNetwork en exécutant la commande suivante : 

    $ oc create -f mlx-dpdk-network.yaml

  5. Pod Enregistrez la configuration YAML suivante dans un fichier mlx-dpdk-pod.yaml: 

    apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 1
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 2
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3
    volumeMounts:
    - mountPath: /dev/hugepages 4
      name: hugepage
    resources:
      limits:
        openshift.io/mlxnics: "1" 5
        memory: "1Gi"
        cpu: "4" 6
        hugepages-1Gi: "4Gi" 7
      requests:
        openshift.io/mlxnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
    1
    Spécifiez le même target_namespace où l'objet SriovNetwork mlx-dpdk-network est créé. Pour créer le pod dans un espace de noms différent, modifiez target_namespace à la fois dans la spécification Pod et dans l'objet SriovNetwork.
    2
    Spécifiez l'image DPDK qui inclut votre application et la bibliothèque DPDK utilisée par l'application.
    3
    Spécifier les capacités supplémentaires requises par l'application à l'intérieur du conteneur pour l'allocation de pages énormes, l'allocation de ressources système et l'accès à l'interface réseau.
    4
    Montez le volume hugepage sur le pod DPDK sous /dev/hugepages. Le volume hugepage est soutenu par le type de volume emptyDir, le support étant Hugepages.
    5
    Facultatif : Spécifiez le nombre de périphériques DPDK alloués pour le module DPDK. Si elle n'est pas explicitement spécifiée, cette demande de ressource et cette limite sont automatiquement ajoutées par l'injecteur de ressources du réseau SR-IOV. L'injecteur de ressources réseau SR-IOV est un composant du contrôleur d'admission géré par l'opérateur SR-IOV. Il est activé par défaut et peut être désactivé en définissant l'option enableInjector sur false dans le CR SriovOperatorConfig par défaut.
    6
    Spécifiez le nombre d'unités centrales. Le pod DPDK nécessite généralement que des CPU exclusifs soient alloués à partir du kubelet. Pour ce faire, définissez la politique du gestionnaire de CPU sur static et créez un pod avec Guaranteed Quality of Service (QoS).
    7
    Spécifiez la taille de la page d'accueil hugepages-1Gi ou hugepages-2Mi et la quantité de pages d'accueil qui seront allouées au module DPDK. Configurez séparément 2Mi et 1Gi hugepages. La configuration de 1Gi hugepages nécessite l'ajout d'arguments de noyau à Nodes.

  6. Créez le module DPDK en exécutant la commande suivante : 

    $ oc create -f mlx-dpdk-pod.yaml

23.10.3. Vue d'ensemble de l'obtention d'un débit de ligne DPDK spécifique

Pour atteindre un débit de ligne spécifique du kit de développement du plan de données (DPDK), déployez un opérateur de réglage de nœud et configurez la virtualisation d'E/S à racine unique (SR-IOV). Vous devez également régler les paramètres du DPDK pour les ressources suivantes :

  • CPU isolés
  • Hugepages
  • Le planificateur de topologie
Note

Dans les versions précédentes d'OpenShift Container Platform, l'opérateur Performance Addon était utilisé pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift Container Platform. Dans OpenShift Container Platform 4.11 et les versions ultérieures, cette fonctionnalité fait partie de l'opérateur Node Tuning.

Environnement de test DPDK

Le diagramme suivant montre les composants d'un environnement de test de trafic :

DPDK test environment
  • Traffic generator: Une application qui peut générer un trafic de paquets important.
  • SR-IOV-supporting NIC: Carte d'interface réseau compatible avec SR-IOV. La carte exécute un certain nombre de fonctions virtuelles sur une interface physique.
  • Physical Function (PF): Fonction PCI Express (PCIe) d'un adaptateur réseau qui prend en charge l'interface SR-IOV.
  • Virtual Function (VF): Une fonction PCIe légère sur un adaptateur de réseau qui prend en charge le SR-IOV. Le VF est associé à la PF PCIe de l'adaptateur réseau. Le VF représente une instance virtualisée de l'adaptateur réseau.
  • Switch: Un commutateur de réseau. Les nœuds peuvent également être connectés dos à dos.
  • testpmd: Une application d'exemple incluse dans le DPDK. L'application testpmd peut être utilisée pour tester le DPDK dans un mode de transmission de paquets. L'application testpmd est également un exemple de construction d'une application complète à l'aide du kit de développement logiciel (SDK) DPDK.
  • worker 0 et worker 1: Nœuds OpenShift Container Platform.

23.10.4. Utilisation du SR-IOV et du Node Tuning Operator pour atteindre un débit de ligne DPDK

Vous pouvez utiliser le Node Tuning Operator pour configurer des CPU isolés, des hugepages et un planificateur de topologie. Vous pouvez ensuite utiliser l'opérateur de réglage de nœud avec la virtualisation d'E/S à racine unique (SR-IOV) pour atteindre un débit de ligne spécifique du kit de développement du plan de données (DPDK).

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous avez installé l'opérateur de réseau SR-IOV.
  • Vous vous êtes connecté en tant qu'utilisateur avec les privilèges cluster-admin.

  • Vous avez déployé un Node Tuning Operator autonome.

    Note

    Dans les versions précédentes d'OpenShift Container Platform, l'opérateur Performance Addon était utilisé pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift. Dans OpenShift Container Platform 4.11 et les versions ultérieures, cette fonctionnalité fait partie de l'opérateur Node Tuning.

Procédure

  1. Créez un objet PerformanceProfile en vous inspirant de l'exemple suivant : 

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  globallyDisableIrqLoadBalancing: true
  cpu:
    isolated: 21-51,73-103 1
    reserved: 0-20,52-72 2
  hugepages:
    defaultHugepagesSize: 1G 3
    pages:
      - count: 32
        size: 1G
  net:
    userLevelNetworking: true
  numa:
    topologyPolicy: "single-numa-node"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
    1
    Si l'hyperthreading est activé sur le système, allouez les liens symboliques appropriés aux groupes de CPU isolated et reserved. Si le système contient plusieurs nœuds d'accès à la mémoire non uniforme (NUMA), allouez les CPU des deux NUMA aux deux groupes. Vous pouvez également utiliser le Créateur de profil de performance pour cette tâche. Pour plus d'informations, voir Creating a performance profile.
    2
    Vous pouvez également spécifier une liste de périphériques dont les files d'attente seront définies en fonction du nombre d'unités centrales réservées. Pour plus d'informations, voir Reducing NIC queues using the Node Tuning Operator.
    3
    Allouer le nombre et la taille des hugepages nécessaires. Vous pouvez spécifier la configuration NUMA pour les hugepages. Par défaut, le système alloue un nombre pair à chaque nœud NUMA du système. Si nécessaire, vous pouvez demander l'utilisation d'un noyau en temps réel pour les nœuds. Pour plus d'informations, voir Provisioning a worker with real-time capabilities pour plus d'informations.
  2. Enregistrez le fichier yaml sous mlx-dpdk-perfprofile-policy.yaml.

  3. Appliquez le profil de performance à l'aide de la commande suivante : 

    $ oc create -f mlx-dpdk-perfprofile-policy.yaml

23.10.4.1. Exemple d'opérateur de réseau SR-IOV pour les fonctions virtuelles

Vous pouvez utiliser l'opérateur de réseau de virtualisation d'E/S à racine unique (SR-IOV) pour allouer et configurer des fonctions virtuelles (VF) à partir de cartes d'interface réseau de fonctions physiques supportant la SR-IOV sur les nœuds.

Pour plus d'informations sur le déploiement de l'opérateur, voir Installing the SR-IOV Network Operator. Pour plus d'informations sur la configuration d'un périphérique réseau SR-IOV, voir Configuring an SR-IOV network device.

Il existe quelques différences entre l'exécution des charges de travail du kit de développement du plan de données (DPDK) sur les VF Intel et les VF Mellanox. Cette section fournit des exemples de configuration d'objets pour les deux types de VF. Voici un exemple d'objet sriovNetworkNodePolicy utilisé pour exécuter des applications DPDK sur des cartes réseau Intel : 

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci 1
  needVhostNet: true 2
  nicSelector:
    pfNames: ["ens3f0"]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  needVhostNet: true
  nicSelector:
    pfNames: ["ens3f1"]
  nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_2
1
Pour les NIC d'Intel, deviceType doit être vfio-pci.
2
Si la communication du noyau avec les charges de travail DPDK est nécessaire, ajoutez needVhostNet: true. Cela permet de monter les périphériques /dev/net/tun et /dev/vhost-net dans le conteneur afin que l'application puisse créer un périphérique de prise et connecter le périphérique de prise à la charge de travail DPDK.

Voici un exemple d'objet sriovNetworkNodePolicy pour les cartes d'interface réseau Mellanox : 

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice 1
  isRdma: true 2
  nicSelector:
    rootDevices:
      - "0000:5e:00.1"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    rootDevices:
      - "0000:5e:00.0"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_2
1
Pour les dispositifs Mellanox, le site deviceType doit être netdevice.
2
Pour les dispositifs Mellanox, isRdma doit être true. Les cartes Mellanox sont connectées aux applications DPDK en utilisant la bifurcation de flux. Ce mécanisme divise le trafic entre l'espace utilisateur Linux et l'espace noyau, et peut améliorer la capacité de traitement du débit de ligne.

23.10.4.2. Exemple d'opérateur de réseau SR-IOV

Voici un exemple de définition d'un objet sriovNetwork. Dans ce cas, les configurations Intel et Mellanox sont identiques : 

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-1
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}' 1
  networkNamespace: dpdk-test 2
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_1 3
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-2
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'
  networkNamespace: dpdk-test
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_2
1
Vous pouvez utiliser une implémentation différente de la gestion des adresses IP (IPAM), telle que Whereabouts. Pour plus d'informations, voir Dynamic IP address assignment configuration with Whereabouts.
2
Vous devez demander l'adresse networkNamespace où la définition de la pièce jointe au réseau sera créée. Vous devez créer le CR sriovNetwork sous l'espace de noms openshift-sriov-network-operator.
3
La valeur de resourceName doit correspondre à celle de resourceName créée sous sriovNetworkNodePolicy.

23.10.4.3. Exemple de charge de travail de base DPDK

Voici un exemple de conteneur du kit de développement du plan de données (DPDK) : 

apiVersion: v1
kind: Namespace
metadata:
  name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[ 1
     {
      "name": "dpdk-network-1",
      "namespace": "dpdk-test"
     },
     {
      "name": "dpdk-network-2",
      "namespace": "dpdk-test"
     }
   ]'
    irq-load-balancing.crio.io: "disable" 2
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
  labels:
    app: dpdk
  name: testpmd
  namespace: dpdk-test
spec:
  runtimeClassName: performance-performance 3
  containers:
    - command:
        - /bin/bash
        - -c
        - sleep INF
      image: registry.redhat.io/openshift4/dpdk-base-rhel8
      imagePullPolicy: Always
      name: dpdk
      resources: 4
        limits:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
        requests:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE
            - NET_RAW
            - NET_ADMIN
        runAsUser: 0
      volumeMounts:
        - mountPath: /mnt/huge
          name: hugepages
  terminationGracePeriodSeconds: 5
  volumes:
    - emptyDir:
        medium: HugePages
      name: hugepages
1
Demandez les réseaux SR-IOV dont vous avez besoin. Les ressources pour les appareils seront injectées automatiquement.
2
Désactiver la base d'équilibrage de charge du CPU et de l'IRQ. Pour plus d'informations, voir Disabling interrupt processing for individual pods pour plus d'informations.
3
Réglez le runtimeClass sur le performance-performance. Ne définissez pas runtimeClass sur HostNetwork ou privileged.
4
Demander un nombre égal de ressources pour les demandes et les limites afin de démarrer le pod avec Guaranteed Qualité de service (QoS).
Note

Ne démarrez pas le pod avec SLEEP puis exécutez dans le pod pour démarrer le testpmd ou la charge de travail DPDK. Cela peut ajouter des interruptions supplémentaires car le processus exec n'est rattaché à aucun processeur.

23.10.4.4. Exemple de script testpmd

Voici un exemple de script pour l'exécution de testpmd: 

#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}

dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02

Cet exemple utilise deux CR sriovNetwork différents. La variable d'environnement contient l'adresse PCI de la fonction virtuelle (VF) qui a été allouée au module. Si vous utilisez le même réseau dans la définition du pod, vous devez diviser le pciAddress. Il est important de configurer les adresses MAC correctes du générateur de trafic. Cet exemple utilise des adresses MAC personnalisées.

23.10.5. Utilisation d'une fonction virtuelle en mode RDMA avec un NIC Mellanox

Important

RDMA over Converged Ethernet (RoCE) est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes d'un point de vue fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

RDMA over Converged Ethernet (RoCE) est le seul mode pris en charge lors de l'utilisation de RDMA sur OpenShift Container Platform.

Conditions préalables

  • Installez le CLI OpenShift (oc).
  • Installer l'opérateur de réseau SR-IOV.
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Créez l'objet SriovNetworkNodePolicy suivant, puis enregistrez le YAML dans le fichier mlx-rdma-node-policy.yaml. 

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-rdma-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 1
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 2
  isRdma: true 3
    1
    Indiquez le code hexadécimal du périphérique du réseau SR-IOV.
    2
    Spécifiez le type de pilote pour les fonctions virtuelles à netdevice.
    3
    Activer le mode RDMA.
    Note

    Voir la section Configuring SR-IOV network devices pour une explication détaillée de chaque option de SriovNetworkNodePolicy.

    Lors de l'application de la configuration spécifiée dans un objet SriovNetworkNodePolicy, l'opérateur SR-IOV peut vidanger les nœuds et, dans certains cas, les redémarrer. L'application d'une modification de configuration peut prendre plusieurs minutes. Assurez-vous au préalable qu'il y a suffisamment de nœuds disponibles dans votre cluster pour gérer la charge de travail expulsée.

    Après l'application de la mise à jour de la configuration, tous les pods de l'espace de noms openshift-sriov-network-operator passeront à l'état Running.

  2. Créez l'objet SriovNetworkNodePolicy en exécutant la commande suivante : 

    $ oc create -f mlx-rdma-node-policy.yaml

  3. Créez l'objet SriovNetwork suivant, puis enregistrez le YAML dans le fichier mlx-rdma-network.yaml. 

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-rdma-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 1
# ...
  vlan: <vlan>
  resourceName: mlxnics
    1
    Spécifier un objet de configuration pour le plugin CNI ipam sous la forme d'un bloc YAML scalaire. Le plugin gère l'attribution des adresses IP pour la définition des pièces jointes.
    Note

    Voir la section "Configuration du réseau supplémentaire SR-IOV" pour une explication détaillée de chaque option sur SriovNetwork.

    Une bibliothèque optionnelle, app-netutil, fournit plusieurs méthodes API pour collecter des informations réseau sur le pod parent d'un conteneur.

  4. Créez l'objet SriovNetworkNodePolicy en exécutant la commande suivante : 

    $ oc create -f mlx-rdma-network.yaml

  5. Créez la spécification Pod suivante, puis enregistrez le YAML dans le fichier mlx-rdma-pod.yaml. 

    apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  namespace: <target_namespace> 1
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-rdma-network
spec:
  containers:
  - name: testpmd
    image: <RDMA_image> 2
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3
    volumeMounts:
    - mountPath: /dev/hugepages 4
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "4" 5
        hugepages-1Gi: "4Gi" 6
      requests:
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
    1
    Spécifiez le même target_namespace où l'objet SriovNetwork mlx-rdma-network est créé. Si vous souhaitez créer le pod dans un espace de noms différent, modifiez target_namespace dans la spécification Pod et dans l'objet SriovNetowrk.
    2
    Spécifiez l'image RDMA qui inclut votre application et la bibliothèque RDMA utilisée par l'application.
    3
    Spécifier les capacités supplémentaires requises par l'application à l'intérieur du conteneur pour l'allocation de pages énormes, l'allocation de ressources système et l'accès à l'interface réseau.
    4
    Monter le volume hugepage sur le pod RDMA sous /dev/hugepages. Le volume hugepage est sauvegardé par le type de volume emptyDir, le support étant Hugepages.
    5
    Spécifiez le nombre de CPU. Le pod RDMA nécessite généralement que des CPU exclusifs soient alloués par le kubelet. Pour ce faire, définissez la politique du gestionnaire de CPU sur static et créez un pod avec Guaranteed QoS.
    6
    Spécifiez la taille de la page d'accueil hugepages-1Gi ou hugepages-2Mi et la quantité de pages d'accueil qui seront allouées au pod RDMA. Configurez 2Mi et 1Gi hugepages séparément. La configuration de 1Gi hugepage nécessite l'ajout d'arguments de noyau à Nodes.

  6. Créez le pod RDMA en exécutant la commande suivante : 

    $ oc create -f mlx-rdma-pod.yaml

23.10.6. Un modèle de pod de test pour les clusters qui utilisent OVS-DPDK sur OpenStack

Le pod testpmd suivant illustre la création d'un conteneur avec des pages énormes, des unités centrales réservées et le port SR-IOV.

Un exemple de pod testpmd 

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-dpdk
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/dpdk1: 1 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/dpdk1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 2
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

1
Le nom dpdk1 dans cet exemple correspond à une ressource SriovNetworkNodePolicy créée par l'utilisateur. Vous pouvez remplacer ce nom par celui d'une ressource que vous créez.
2
Si votre profil de performance ne s'appelle pas cnf-performance profile, remplacez cette chaîne par le nom correct du profil de performance.

23.10.7. Un modèle de pod de test pour les clusters qui utilisent le déchargement matériel OVS sur OpenStack

Le pod testpmd suivant démontre le déchargement matériel d'Open vSwitch (OVS) sur Red Hat OpenStack Platform (RHOSP).

Un exemple de pod testpmd 

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile 1
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

1
Si votre profil de performance ne s'appelle pas cnf-performance profile, remplacez cette chaîne par le nom correct du profil de performance.

23.10.8. Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.