Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Utiliser Onload

Cette page explique comment utiliser Onload avec des instances Compute Engine U4.

À propos d'Onload

Onload est une pile réseau haute performance pour les applications sensibles à la latence qui nécessitent une latence ultra-faible, une gigue minimale et des performances constantes. Onload fournit une implémentation TCP/IP qui contourne le noyau du système d'exploitation et s'exécute directement dans l'espace utilisateur, tout en permettant aux applications d'utiliser des API de socket BSD standards.

L'utilisation d'Onload avec la solution ULL inclut la prise en charge des éléments suivants :

Direction de flux : vous pouvez contourner le hachage RSS (Receive Side Scaling) par défaut en dirigeant des flux de trafic spécifiques directement vers une file d'attente de réception (RX) désignée. La direction de flux à trois tuples est prise en charge (protocole, adresse IP de destination, port de destination).

Avant de commencer

Avant d'utiliser Onload sur des instances Compute Engine U4, vous devez répondre aux exigences suivantes.

Créer une instance U4

Si ce n'est pas déjà fait, créez une instance Compute Engine U4 à l'aide de l'une des procédures suivantes, qui incluent la configuration requise pour Onload :

Pour créer une instance Bare Metal U4P ou U4C, consultez Créer des instances Compute Engine ULL.
Pour créer une instance de machine virtuelle (VM) U4S, consultez Créer des instances Compute Engine non ULL pour les charges de travail auxiliaires.

Se connecter à votre instance à l'aide de SSH

Si ce n'est pas déjà fait, connectez-vous à votre instance à l'aide de SSH.

Passer à l'utilisateur racine

Les commandes et les scripts des procédures suivantes modifient les paramètres au niveau du système, les paramètres du noyau et les interfaces réseau. Pour les exécuter correctement, vous devez les exécuter en tant qu'utilisateur racine. Vous pouvez passer à un shell racine en exécutant sudo su, ou ajouter sudo avant d'exécuter des commandes, si nécessaire.

Configurer Onload

Cette section décrit les étapes requises pour configurer Onload sur une instance U4.

Installer des dépendances

Si vous utilisez Rocky Linux, activez le dépôt CodeReady Builder (CRB). Si vous utilisez Red Hat Enterprise Linux (RHEL), ignorez cette étape.
```
dnf -y config-manager --enable crb
```

Installez les dépendances requises pour Onload :

dnf -y install git clang \
   python3-setuptools \
   linuxptp \
   libcap-devel libbpf-devel libxdp-devel

Extraire la source Onload

Pour extraire le onload dépôt avec les modifications requises, exécutez les commandes suivantes :

umask 0022
mkdir -p /usr/src/

git clone https://github.com/Xilinx-CNS/onload /usr/src/onload

# 9.2.0.43 / 9.2.1, origin/v9_2 as of May 18, 2026
git -C /usr/src/onload checkout origin/v9_2

# Pull Google-specific Onload changes not yet merged as of v9_2
curl -L https://github.com/Xilinx-CNS/onload/pull/279.patch | git -C /usr/src/onload am
curl -L https://github.com/Xilinx-CNS/onload/pull/282.patch | git -C /usr/src/onload am
curl -L https://github.com/Xilinx-CNS/onload/pull/325.patch | git -C /usr/src/onload am
curl -L https://github.com/Xilinx-CNS/onload/pull/327.patch | git -C /usr/src/onload am

Compiler Onload

Pour compiler Onload, exécutez les commandes suivantes :

cd /usr/src/onload
USEONLOADEXT=1 ./scripts/onload_install --no-sfc

pushd ./src/tools/bpf_link_helper
clang xdp_onload_prepare.c  -lbpf -o xdp_onload_prepare
clang -target bpf -O2 -g -c xdp_tstamp.c -o ./xdp_tstamp.o
popd

Désactiver le suivi de branche indirect (IBT)

Vous devez désactiver IBT pour utiliser Onload, comme décrit dans Incompatibilité du suivi de branche indirect (IBT) .

Pour désactiver IBT, exécutez les commandes suivantes :

grubby --args="ibt=off" --update-kernel=ALL
reboot

Charger Onload

Cette section explique comment charger Onload sur votre instance.

Charger Onload sur une instance U4P ou U4C

Pour charger Onload sur une instance Bare Metal U4P ou U4C, utilisez le script suivant.

IFNAMES=($( find /sys/class/net -type l -not -lname '*virtual*' -printf '%l %f\n' | sort | awk '{print $2}'))

for IFNAME in "${IFNAMES[@]}"; do
  ethtool -L "${IFNAME}" rx 16 tx 16
  ethtool -G "${IFNAME}" rx 1024 rx-buf-len 2048
  ethtool -K "${IFNAME}" ntuple on
  echo 0 > "/sys/class/net/${IFNAME}/threaded"
  /usr/src/onload/src/tools/bpf_link_helper/xdp_onload_prepare \
    "${IFNAME}" /usr/src/onload/src/tools/bpf_link_helper/xdp_tstamp.o
done

setenforce 0
numactl --cpunodebind=0,2 onload_tool reload --onload-only
for IFNAME in "${IFNAMES[@]}"; do
  echo "${IFNAME}" 16 > /sys/module/sfc_resource/afxdp/register
  until [[ $(cat "/sys/class/net/${IFNAME}/carrier") == 1 ]]; do
    sleep 1
  done
  hwstamp_ctl -i "${IFNAME}" -r 1
done

echo 1 > /sys/module/sfc_resource/parameters/enable_af_xdp_flow_filters
echo 256 > /sys/module/onload/parameters/xdp_headroom
echo -1 > /sys/module/onload/parameters/inject_kernel_gid

Charger Onload sur une instance U4S

Pour charger Onload sur une instance de VM U4S, utilisez le script suivant.

IFNAME=NIC_NAME
ALLOCATED_QUEUES=ALLOCATED_QUEUES

ethtool -L "$IFNAME" rx "${ALLOCATED_QUEUES}" tx "${ALLOCATED_QUEUES}"
ethtool -G "$IFNAME" rx 1024 rx-buf-len 2048
ethtool -K "$IFNAME" ntuple on
echo 0 > "/sys/class/net/${IFNAME}/threaded"
/usr/src/onload/src/tools/bpf_link_helper/xdp_onload_prepare "$IFNAME" \
  /usr/src/onload/src/tools/bpf_link_helper/xdp_tstamp.o

setenforce 0
numactl --cpunodebind=0 onload_tool reload --onload-only

echo "${IFNAME} ${ALLOCATED_QUEUES}" | tee /sys/module/sfc_resource/afxdp/register
until [[ $(cat "/sys/class/net/${IFNAME}/carrier") == 1 ]]; do
    sleep 1
done
hwstamp_ctl -i "$IFNAME" -r 1

echo 1 > /sys/module/sfc_resource/parameters/enable_af_xdp_flow_filters
echo 256 > /sys/module/onload/parameters/xdp_headroom
echo -1 > /sys/module/onload/parameters/inject_kernel_gid

Remplacez les éléments suivants :

NIC_NAME : nom du système d'exploitation de l'interface réseau, par exemple enp22s0f0.
ALLOCATED_QUEUES: nombre de files d'attente de réception (RX) et de transmission (TX) à allouer pour Onload sur l'interface réseau. Définissez cette valeur sur la moitié du nombre total de files d'attente RX ou TX attribuées à la vNIC.

Pour les instances U4S, le nombre total de files d'attente (pour les files d'attente RX ou TX respectivement) est égal à num_vcpus / num_vnics, jusqu'à un maximum de 16 files d'attente par vNIC. Par exemple, si la vNIC comporte 4 files d'attente TX au total, définissez cette valeur sur 2. Si la vNIC comporte 16 files d'attente TX au total, définissez cette valeur sur 8.

Pour en savoir plus sur l'allocation de files d'attente par défaut, consultez Files d'attente de réception et de transmission.

Configurer les options Onload

Pour optimiser les performances et réduire la latence, vous pouvez utiliser l'ensemble suivant de variables d'environnement et d'options lorsque vous exécutez vos applications avec Onload. Cette section inclut les paramètres recommandés que vous pouvez ajuster selon les besoins de vos applications.

Vous devez spécifier ces paramètres avant les commandes de votre application. Par exemple, pour exécuter une application avec ces paramètres, utilisez le format suivant :

env EF_NO_FAIL=0 \
  EF_POLL_USEC=100000 \
  EF_RX_TIMESTAMPING=3 \
  EF_MAX_ENDPOINTS=1048576 \
  EF_WODA_SINGLE_INTERFACE=1 \
  EF_UL_EPOLL=3 \
  EF_USE_HUGE_PAGES=0 \
  EF_EPOLL_CTL_HANDOFF=0 \
  EF_FDS_MT_SAFE=0 \
  EF_NONAGLE_INFLIGHT_MAX=-1 \
  EF_RXQ_SIZE=4096 \
  EF_TCP_RCVBUF_ESTABLISHED_DEFAULT=65536 \
  EF_MAX_PACKETS=65536 \
  EF_PREFAULT_PACKETS=65536 \
  EF_EVS_PER_POLL=256 \
  onload -v --profile=latency APPLICATION_COMMAND

Décharger Onload

Pour décharger Onload, utilisez le script suivant.

IFNAMES=($( find /sys/class/net -type l -not -lname '*virtual*' -printf '%l %f\n' | sort | awk '{print $2}'))

for IFNAME in "${IFNAMES[@]}"; do
  rm -f "/sys/fs/bpf/onload_xdp_xsk_${IFNAME}"
done

onload_tool unload --onload-only

for IFNAME in "${IFNAMES[@]}"; do
  # (optional) Disable threaded busypolling in case it's up. See busypolling
  # section
  echo 0 > "/sys/class/net/${IFNAME}/threaded"

  ip link set dev "${IFNAME}" xdp off
done

Configurer un service `systemd` qui démarre automatiquement Onload

Pour démarrer automatiquement Onload au démarrage de votre instance, vous pouvez l'enregistrer en tant que systemd service. Créez un fichier de service à l'aide du modèle suivant :

[Unit]
Description=ULL Solution -- Loading & instance tuning for Onload
After=network-online.target
After=google-guest-agent-manager.service google-guest-agent.service
Before=multi-user.target
Before=sshd.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=START_SCRIPT_PATH
ExecStartPost=OPTIMIZATION_SCRIPT_PATH
ExecStop=STOP_SCRIPT_PATH

[Install]
WantedBy=multi-user.target

Remplacez les éléments suivants :

START_SCRIPT_PATH : chemin d'accès au script qui démarre Onload, par exemple l'un des scripts de Charger Onload.
OPTIMIZATION_SCRIPT_PATH: chemin d'accès au script facultatif qui applique les configurations d'optimisation. Si vous le souhaitez, vous pouvez créer un script qui inclut vos optimisations des performances et l'inclure ici. Sinon, vous pouvez supprimer la ligne qui inclut cette variable.
STOP_SCRIPT_PATH : chemin d'accès au script qui arrête Onload, par exemple le script de Décharger Onload.

Configurer l'interrogation active

Cette section fournit des exemples de configuration de l'interrogation active sur votre instance.

L'interrogation active vérifie en permanence les nouveaux paquets réseau au lieu d'attendre les interruptions de l'appareil, ce qui permet de réduire la latence et la gigue. Pour en savoir plus sur l'interrogation active, consultez Interrogation active dans la documentation sur le noyau Linux.

Obtenir la file d'attente RX utilisée par une pile Onload

Pour obtenir la file d'attente RX utilisée par une pile Onload, procédez comme suit :

Obtenez l'ID de la pile Onload en exécutant onload_stackdump :
```
onload_stackdump
```

Étant donné que l'ID de la pile Onload et l'ID de la file d'attente NAPI ne correspondent pas toujours, utilisez le script suivant pour obtenir le nom de l'interface, l'index et l'ID de la file d'attente correspondants à partir d'un ID de pile.

ONLOAD_STACK=ONLOAD_STACK_ID

INTF_HWPORT_MAP=($(onload_stackdump "${ONLOAD_STACK}" netif_extra | grep -oP "intf_i_to_hwport=\K.*$" | tr ',' '\n'))
HWPORT_IFINDEX_MAP=($(onload_stackdump "${ONLOAD_STACK}" hwport_to_base_ifindex | grep -oP "\d+$"))
while read -r INTF_ID QUEUE_ID; do
HW_PORT="${INTF_HWPORT_MAP[INTF_ID]}"
IFINDEX="${HWPORT_IFINDEX_MAP[HW_PORT]}"
IFNAME=$(ip -j link | jq -r ".[] | select(.ifindex == ${IFINDEX}) | .ifname")
echo "ifname=${IFNAME} ifindex=${IFINDEX} queue_id=${QUEUE_ID}"
done < <(onload_stackdump "${ONLOAD_STACK}" netif | grep -oP "((intf|vi)=)\K\d+" | xargs -n 2)

Remplacez ONLOAD_STACK_ID par l'ID de la pile pour laquelle vous souhaitez activer ou désactiver l'interrogation active.

Enregistrez les valeurs à utiliser lorsque vous activez ou désactivez l'interrogation active dans les sections suivantes.

Activer l'interrogation active sur une file d'attente RX

Cette section fournit un exemple d'activation de l'interrogation active sur une file d'attente RX spécifique utilisée par une pile Onload.

Exécutez le script bash suivant dans votre terminal. La fonction enable_single_queue effectue les opérations suivantes :

Obtient le napi_id qui correspond à une file d'attente RX à l'aide de netlink (ynl)
Définit la propriété threaded: busy-poll sur le napi_id
Obtient le kthread_pid du thread qui interroge activement le napi_id
Utilise taskset pour lier le kthread_pid à un processeur spécifique

readonly NETDEV_YAML=${NETDEV_YAML:-"/usr/share/ynl/specs/netdev.yaml"}

call_ynl() {
  ynl --spec "${NETDEV_YAML}" "$@"
}

enable_single_queue() {
  local -r interface="$1"
  local -r ifindex=$(cat "/sys/class/net/${interface}/ifindex")
  local -r q_id="$2"
  local -r cpu="$3"

  local napi_id
  napi_id=$(call_ynl --output-json --do queue-get \
    --json "{\"ifindex\": ${ifindex}, \"id\": ${q_id}, \"type\": \"rx\"}" | \
    jq -r '."napi-id"')

  if [[ -z "${napi_id}" || "${napi_id}" == "null" ]]; then
    echo "Error: No napi_id found for queue ${q_id} on interface ${interface}" >&2
    exit 1
  fi

  echo "Enabling busypolling for queue ${q_id} (NAPI ${napi_id}) on CPU ${cpu}"
  call_ynl --do napi-set --json "{\"id\": \"${napi_id}\", \"threaded\": \"busy-poll\"}" >/dev/null

  local napi_kthread_pid
  napi_kthread_pid=$(call_ynl --do napi-get --output-json \
    --json "{\"id\": \"${napi_id}\"}" | jq -r '."pid" // empty')

  if [[ -z "${napi_kthread_pid}" ]]; then
    echo "Error: Could not get PID for NAPI ${napi_id}" >&2
    exit 1
  fi

  taskset -pc "${cpu}" "${napi_kthread_pid}" >/dev/null
}

Exécutez la commande suivante pour appeler la fonction enable_single_queue :
```
enable_single_queue NIC_NAME QUEUE_ID CPU_ID
```
Remplacez les éléments suivants :
- NIC_NAME: nom du système d'exploitation de l'interface réseau, par exemple ens8f0.
- QUEUE_ID : ID de la file d'attente que vous avez obtenu précédemment.
- CPU_ID: ID du processeur sur lequel exécuter le thread d'interrogation active, par exemple 5.
Assurez-vous de planifier les événements de recréation de thread qui peuvent affecter votre configuration d'interrogation active.

Planifier les événements de recréation de thread

Lorsque le noyau recrée un thread, les configurations de thread associées ne sont pas conservées, telles que son masque d'affinité de processeur et sa stratégie de planification. Les événements suivants entraînent la recréation par le noyau d'un thread qui interroge activement NAPI :

Flaps/Réinitialisations de lien
Pièces jointes de programme XDP (par exemple, lors de l'exécution des scripts pour charger Onload ou de la pièce jointe de programmes XDP personnalisés)
Modifications des paramètres de l'anneau (ethtool -G)
Modifications du nombre de files d'attente (ethtool -L)

Pour éviter les problèmes, évitez les tâches qui entraînent des événements de recréation de thread lors des opérations normales.

Pour conserver votre configuration d'interrogation active après la recréation d'un thread, vous devez obtenir le nouvel ID de processus (PID) du thread et le relier au processeur. Pour ce faire, exécutez à nouveau la enable_single_queue fonction.

Désactiver l'interrogation active sur une file d'attente RX

Cette section fournit un exemple de désactivation de l'interrogation active sur une file d'attente RX spécifique utilisée par une pile Onload.

Obtenez la file d'attente RX utilisée par une pile Onload en exécutant onload_stackdump :
```
onload_stackdump
```

Exécutez le script bash suivant dans votre terminal. La fonction disable_single_queue effectue les opérations suivantes :

Obtient le napi_id qui correspond à une file d'attente RX à l'aide de netlink (ynl)
Définit la propriété de thread du napi_id sur disabled

disable_single_queue() {
  local -r interface="$1"
  local -r ifindex=$(cat "/sys/class/net/${interface}/ifindex")
  local -r q_id="$2"

  local napi_id
  napi_id=$(call_ynl --output-json --do queue-get \
    --json "{\"ifindex\": ${ifindex}, \"id\": ${q_id}, \"type\": \"rx\"}" | \
    jq -r '."napi-id"')

  if [[ -z "${napi_id}" || "${napi_id}" == "null" ]]; then
    echo "Error: No napi_id found for queue ${q_id} on interface ${interface}" >&2
    exit 1
  fi

  echo "Disabling busypolling for queue ${q_id} (NAPI ${napi_id})"
  call_ynl --do napi-set --json "{\"id\": \"${napi_id}\", \"threaded\": \"disabled\"}" >/dev/null
}

Exécutez la commande suivante pour appeler la fonction disable_single_queue :
```
disable_single_queue NIC_NAME QUEUE_ID
```
Remplacez les éléments suivants :
- NIC_NAME: nom du système d'exploitation de l'interface réseau, par exemple ens8f0.
- QUEUE_ID : ID de la file d'attente que vous avez obtenu précédemment.

Obtenir l'état d'interrogation active d'une file d'attente

Pour vérifier l'état NAPI d'une file d'attente et déterminer si elle interroge activement, vous pouvez utiliser les commandes suivantes :

IFNAME=NIC_NAME
QUEUE_ID=QUEUE_ID
QUEUE_TYPE=QUEUE_TYPE

IFINDEX=$(cat "/sys/class/net/${IFNAME}/ifindex")
NAPI_ID=$(ynl --spec /usr/share/ynl/specs/netdev.yaml \
  --output-json --do queue-get \
  --json '{"ifindex": '${IFINDEX}', "id": '${QUEUE_ID}', "type": "'${QUEUE_TYPE}'"}' | \
  jq '."napi-id"')
ynl --spec /usr/share/ynl/specs/netdev.yaml \
  --output-json --do napi-get \
  --json '{"id": '${NAPI_ID}'}' | jq -r '"status: \(.threaded)"'

Remplacez les éléments suivants :

NIC_NAME: nom du système d'exploitation de l'interface réseau, par exemple ens8f0.
QUEUE_ID : ID de la file d'attente que vous souhaitez vérifier.
QUEUE_TYPE : rx ou tx.

Optimiser les performances

Cette section fournit des conseils généraux pour optimiser les performances de vos instances Bare Metal U4 (U4P et U4C). Ajustez les exemples de ces conseils en fonction des besoins de vos charges de travail.

Examiner la topologie NUMA pour les instances Bare Metal U4

Le tableau suivant décrit les interfaces réseau qui utilisent les nœuds NUMA pour les instances Bare Metal U4 :

NIC (Google Cloud nom)	NIC (nom du système d'exploitation)	Nœud NUMA	PCIE BDF
`nic0`	`enp22s0f0`	0	`0000:16:00.0`
`nic1`	`ens8f0`	0	`0000:27:00.0`
`nic2`	`ens48f0`	2	`0000:b8:00.0`

Le tableau précédent inclut les noms d'interface réseau attribués par le système d'exploitation pour RHEL. Les noms réels peuvent être différents.

Déterminer un schéma d'isolation du processeur

Pour des performances optimales, nous vous recommandons d'isoler les éléments suivants :

Les processeurs utilisés par votre application
Les processeurs utilisés pour interroger activement les files d'attente RX Onload
Les processeurs utilisés pour les interruptions du noyau et du pilote

Le tableau suivant fournit un exemple d'isolation des processeurs sur les instances Bare Metal U4. Ajustez le mappage en fonction des besoins de vos charges de travail. Par exemple, vous pouvez avoir besoin de plus de processeurs d'application.

Objectif	Processeurs
Interruptions générales du noyau	0,1,30,31,60,61,90,91
Interruptions du pilote `nic0` pour les files d'attente 0 à 11	2
Interruptions du pilote `nic1` pour les files d'attente 0 à 11	3
Interruptions du pilote `nic0` et `nic1` pour les files d'attente 12 à 15	4
Interrogation active `nic1`	5-16
Threads d'application `nic1` (Onload)	17-29
Interrogation active `nic0`	32-43
Threads d'application `nic0` (Onload)	44-59
Interruptions du pilote `nic2` pour les files d'attente 0 à 11	62
Interruptions du pilote `nic2` pour les files d'attente 12 à 15	63
Interrogation active `nic2`	64-75
Threads d'application `nic2` (Onload)	76-89

Installer des dépendances pour l'optimisation des performances

Pour installer les dépendances requises pour l'optimisation des performances, exécutez la commande suivante :

dnf -y install numactl tuna jq

Configurer les paramètres de démarrage du noyau

Pour isoler les processeurs de la planification du noyau, exécutez la commande suivante. Cela désactive également Intel QuickAssist Technology (QAT) afin qu'elle n'interfère pas avec vos cœurs isolés.

L'exemple de commande suivant isole les processeurs 2-29, 32-59 et 62-89, et désigne 0,1,30,31,60,61,90,91 pour les interruptions générales du noyau. Ces valeurs correspondent au schéma d'isolation du processeur. Remplacez les valeurs selon les besoins en fonction de votre schéma d'isolation du processeur.

grubby --args="isolcpus=domain,managed_irq,2-29,32-59,62-89 nohz=on nohz_full=2-29,32-59,62-89 rcu_nocbs=2-29,32-59,62-89 irqaffinity=0,1,30,31,60,61,90,91 rcu_nocb_poll modprobe.blacklist=intel_qat,qat_4xxx" --update-kernel=ALL
reboot

Configurer l'isolation du processeur après le démarrage

Pour isoler les processeurs après le démarrage, exécutez la commande suivante. Les valeurs correspondent au schéma d'isolation du processeur exemple. Remplacez les valeurs selon les besoins en fonction de votre schéma d'isolation du processeur.

tuna isolate -c 2-29,32-59,62-89

Attribuer des interruptions de file d'attente à des processeurs spécifiques

Cette section explique comment déplacer les requêtes d'interruption de file d'attente gve (IRQ) vers des processeurs spécifiques. Le pilote gve est utilisé par le type d'interface réseau GVNIC dans Google Cloud.

Déterminez les IRQ pour une interface réseau et une plage de files d'attente données. Consultez l'exemple bash suivant, qui définit une fonction irq_list.

irq_list() {
  local ifname=$1
  local queue_begin=$2
  local queue_end=$3

  pci_name=$(basename $(readlink /sys/class/net/${ifname}/device))
  rx_ntfy_blk_start=$(ethtool -l "${ifname}" | awk '
    /Pre-set maximums:/ { in_preset = 1 }
    /Current hardware settings:/ { in_preset = 0 }
    in_preset && $1 == "RX:" { rx = $2 }
    in_preset && $1 == "TX:" { tx = $2 }
    END { print int((rx + tx) / 2) }
  ')
  for i in $(seq "${queue_begin}" "${queue_end}"); do
    irq_tx="gve-ntfy-blk${i}@pci:${pci_name}"
    irq_rx="gve-ntfy-blk$(($i + rx_ntfy_blk_start))@pci:${pci_name}"
    # gve IRQ names are stored in a char[IFNAMSIZ + 16] so capped to 31 characters.
    echo "${irq_tx:0:31}"
    echo "${irq_rx:0:31}"
  done | paste -sd ','
}

Attribuez des IRQ au processeur approprié en fonction de votre schéma d'isolation du processeur. L'exemple de script suivant utilise tuna et la fonction irq_list de l'étape précédente :

tuna move -c 2 -q "$(irq_list enp22s0f0 0 11)"
tuna move -c 4 -q "$(irq_list enp22s0f0 12 15)"

tuna move -c 3 -q "$(irq_list ens8f0 0 11)"
tuna move -c 4 -q "$(irq_list ens8f0 12 15)"

tuna move -c 62 -q "$(irq_list ens48f0 0 11)"
tuna move -c 63 -q "$(irq_list ens48f0 12 15)"

Configurer les paramètres du système d'exploitation et de l'appareil

Exécutez le script suivant pour configurer les paramètres qui permettent de réduire la latence et d'empêcher les comportements par défaut du système d'exploitation d'interférer avec vos configurations Onload.

echo 0 > /proc/sys/net/core/busy_poll
echo 0 > /proc/sys/net/core/busy_read
echo 0 > /proc/sys/kernel/timer_migration
echo 0 > /proc/sys/net/core/rps_sock_flow_entries
echo -1 > /proc/sys/kernel/sched_rt_runtime_us

for IFNAME in "${IFNAMES[@]}"; do
  ethtool -C "${IFNAME}" rx-usecs 0 tx-usecs 0
  echo 0 > "/sys/class/net/${IFNAME}/napi_defer_hard_irqs"
  echo 15000 > "/sys/class/net/${IFNAME}/gro_flush_timeout"
done

Pour détourner le trafic des files d'attente dédiées aux charges de travail Onload, utilisez RSS (ethtool -X). L'exemple de script suivant est basé sur les valeurs dans l'exemple de schéma d'isolation du processeur. Étant donné qu'Onload utilise les files d'attente 0-11, le script dirige tout autre trafic vers les files d'attente 12-15.
```
for IFNAME in "${IFNAMES[@]}"; do
  ethtool -X "${IFNAME}" weight 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1
done
```

Étape suivante

Pour synchroniser l'horloge système de votre instance avec l'horloge de la carte d'interface réseau physique de son serveur hôte, consultez Configurer l'heure exacte.

Utiliser Onload

À propos d'Onload

Avant de commencer

Créer une instance U4

Se connecter à votre instance à l'aide de SSH

Passer à l'utilisateur racine

Configurer Onload

Installer des dépendances

Extraire la source Onload

Compiler Onload

Désactiver le suivi de branche indirect (IBT)

Charger Onload

Charger Onload sur une instance U4P ou U4C

Charger Onload sur une instance U4S

Configurer les options Onload

Décharger Onload

Configurer un service systemd qui démarre automatiquement Onload

Configurer l'interrogation active

Obtenir la file d'attente RX utilisée par une pile Onload

Activer l'interrogation active sur une file d'attente RX

Planifier les événements de recréation de thread

Désactiver l'interrogation active sur une file d'attente RX

Obtenir l'état d'interrogation active d'une file d'attente

Optimiser les performances

Examiner la topologie NUMA pour les instances Bare Metal U4

Déterminer un schéma d'isolation du processeur

Installer des dépendances pour l'optimisation des performances

Configurer les paramètres de démarrage du noyau

Configurer l'isolation du processeur après le démarrage

Attribuer des interruptions de file d'attente à des processeurs spécifiques

Configurer les paramètres du système d'exploitation et de l'appareil

Étape suivante

Configurer un service `systemd` qui démarre automatiquement Onload