Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Utilizzare Onload

Questa pagina descrive come utilizzare Onload con le istanze U4 di Compute Engine.

Informazioni su Onload

Onload è uno stack di rete ad alte prestazioni per applicazioni sensibili alla latenza che richiedono una latenza molto bassa, un jitter minimo e prestazioni costanti. Onload fornisce un'implementazione TCP/IP che ignora il kernel del sistema operativo e viene eseguita direttamente nello spazio utente, consentendo alle applicazioni di utilizzare le API socket BSD standard.

L'utilizzo di Onload con la soluzione ULL include il supporto per quanto segue:

Steering del flusso: puoi ignorare l'hashing RSS (Receive Side Scaling) predefinito indirizzando flussi di traffico specifici direttamente a una coda di ricezione (RX) designata. È supportato lo steering del flusso a 3 tuple (protocollo, indirizzo IP di destinazione, porta di destinazione).

Prima di iniziare

Prima di utilizzare Onload sulle istanze U4 di Compute Engine, devi soddisfare i seguenti requisiti.

Creare un'istanza U4

Se non l'hai già fatto, crea un'istanza U4 di Compute Engine utilizzando una delle seguenti procedure che includono la configurazione richiesta per Onload:

Per creare un'istanza bare metal U4P o U4C, consulta Creare istanze ULL di Compute Engine.
Per creare un'istanza di macchina virtuale (VM) U4S, consulta Creare istanze di Compute Engine non ULL per workload ausiliari.

Connettersi all'istanza utilizzando SSH

Se non l'hai già fatto, connettiti all'istanza utilizzando SSH.

Passare all'utente root

I comandi e gli script nelle procedure seguenti modificano le impostazioni a livello di sistema, i parametri del kernel e le interfacce di rete. Per eseguirli correttamente, devi eseguirli come utente root. Puoi passare a una shell root eseguendo sudo su o aggiungere sudo prima di eseguire i comandi, se necessario.

Configurare Onload

Questa sezione descrive i passaggi necessari per configurare Onload su un'istanza U4.

Installare le dipendenze

Se utilizzi Rocky Linux, attiva il repository CodeReady Builder (CRB). Se utilizzi Red Hat Enterprise Linux (RHEL), salta questo passaggio.
```
dnf -y config-manager --enable crb
```

Installa le dipendenze richieste per Onload:

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

Recuperare l'origine Onload

Per recuperare il onload repository con le modifiche richieste, esegui i seguenti comandi:

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

Creare Onload

Per creare Onload, esegui i seguenti comandi:

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

Disattivare il monitoraggio dei rami indiretti (IBT)

Per utilizzare Onload, come descritto in Incompatibilità del monitoraggio dei rami indiretti (IBT) , è necessario disattivare IBT.

Per disattivare IBT, esegui i seguenti comandi:

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

Caricare Onload

Questa sezione descrive come caricare Onload sull'istanza.

Caricare Onload su un'istanza U4P o U4C

Per caricare Onload su un'istanza bare metal U4P o U4C, utilizza il seguente script.

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

Caricare Onload su un'istanza U4S

Per caricare Onload su un'istanza VM U4S, utilizza il seguente script.

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

Sostituisci quanto segue:

NIC_NAME: il nome del sistema operativo dell'interfaccia di rete, ad esempio enp22s0f0.
ALLOCATED_QUEUES: il numero di code di ricezione (RX) e trasmissione (TX) da allocare per Onload sull'interfaccia di rete. Imposta questo valore sulla metà del numero totale di code RX o TX assegnate alla vNIC.

Per le istanze U4S, il conteggio totale delle code (rispettivamente per le code RX o TX) è uguale a num_vcpus / num_vnics, fino a un massimo di 16 code per vNIC. Ad esempio, se la vNIC ha 4 code TX totali, imposta questo valore su 2. Se la vNIC ha 16 code TX totali, imposta questo valore su 8.

Per ulteriori informazioni sull'allocazione predefinita delle code, consulta Code di ricezione e trasmissione.

Configurare i flag Onload

Per ottimizzare le prestazioni e ridurre la latenza, puoi utilizzare il seguente insieme di variabili di ambiente e flag quando esegui le applicazioni con Onload. Questa sezione include le impostazioni consigliate che puoi modificare in base alle esigenze delle tue applicazioni.

Devi specificare questi parametri prima dei comandi dell'applicazione. Ad esempio, per eseguire un'applicazione con queste impostazioni, utilizza il seguente formato:

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

Eseguire l'unload di Onload

Per eseguire l'unload di Onload, utilizza il seguente script.

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

Configurare un servizio `systemd` che avvia automaticamente Onload

Per avviare automaticamente Onload all'avvio dell'istanza, puoi registrarlo come un systemd servizio. Crea un file di servizio utilizzando il seguente modello:

[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

Sostituisci quanto segue:

START_SCRIPT_PATH: il percorso dello script che avvia Onload, ad esempio uno degli script in Caricare Onload.
OPTIMIZATION_SCRIPT_PATH: il percorso dello script facoltativo che applica le configurazioni di ottimizzazione. Se vuoi, puoi creare uno script che includa le ottimizzazioni delle prestazioni e includerlo qui. In caso contrario, puoi rimuovere la riga che include questa variabile.
STOP_SCRIPT_PATH: il percorso dello script che arresta Onload, ad esempio lo script in Eseguire l'unload di Onload.

Configurare il polling occupato

Questa sezione fornisce esempi di come configurare il polling occupato sull'istanza.

Il polling occupato controlla continuamente la presenza di nuovi pacchetti di rete anziché attendere gli interrupt del dispositivo, il che contribuisce a ridurre la latenza e il jitter. Per ulteriori informazioni sul polling occupato, consulta Polling occupato nella documentazione del kernel Linux.

Recuperare la coda RX utilizzata da uno stack Onload

Per recuperare la coda RX utilizzata da uno stack Onload:

Recupera l'ID dello stack Onload eseguendo onload_stackdump:
```
onload_stackdump
```

Poiché l'ID dello stack Onload e l'ID della coda NAPI potrebbero non corrispondere sempre, utilizza il seguente script per recuperare il nome dell'interfaccia, l'indice e l'ID della coda corrispondenti da un ID dello stack.

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)

Sostituisci ONLOAD_STACK_ID con l'ID dello stack per il quale vuoi attivare o disattivare il polling occupato.

Registra i valori da utilizzare quando attivi o disattivi il polling occupato nelle sezioni seguenti.

Attivare il polling occupato su una coda RX

Questa sezione fornisce un esempio di come attivare il polling occupato su una coda RX specifica utilizzata da uno stack Onload.

Esegui il seguente script bash nel terminale. La funzione enable_single_queue esegue le seguenti operazioni:

Recupera l'napi_id corrispondente a una coda RX utilizzando netlink (ynl)
Imposta la proprietà threaded: busy-poll sull'napi_id
Recupera il kthread_pid del thread che esegue il polling occupato dell'napi_id
Utilizza taskset per associare il kthread_pid a una CPU specifica

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
}

Esegui il seguente comando per richiamare la funzione enable_single_queue:
```
enable_single_queue NIC_NAME QUEUE_ID CPU_ID
```
Sostituisci quanto segue:
- NIC_NAME: il nome del sistema operativo dell'interfaccia di rete, ad esempio ens8f0.
- QUEUE_ID: l'ID della coda recuperato in precedenza.
- CPU_ID: l'ID della CPU su cui eseguire il thread di polling occupato, ad esempio 5.
Assicurati di pianificare gli eventi di ricreazione dei thread che potrebbero influire sulla configurazione del polling occupato.

Pianificare gli eventi di ricreazione dei thread

Quando il kernel ricrea un thread, le configurazioni dei thread associati, come la maschera di affinità della CPU e la policy di pianificazione, non vengono mantenute. Eventi come i seguenti fanno sì che il kernel ricrei un thread che esegue il polling occupato di NAPI:

Flap/reimpostazioni dei link
Allegati del programma XDP (ad esempio, quando si eseguono gli script per caricare Onload o si collegano programmi XDP personalizzati)
Modifiche dei parametri dell'anello (ethtool -G)
Modifiche del conteggio delle code (ethtool -L)

Per evitare problemi, valuta la possibilità di evitare le attività che causano eventi di ricreazione dei thread durante le normali operazioni.

Per mantenere la configurazione del polling occupato dopo la ricreazione di un thread, devi ottenere il nuovo ID processo (PID) del thread e riassociarlo alla CPU. Puoi farlo eseguendo di nuovo la enable_single_queue funzione.

Disattivare il polling occupato su una coda RX

Questa sezione fornisce un esempio di come disattivare il polling occupato su una coda RX specifica utilizzata da uno stack Onload.

Recupera la coda RX utilizzata da uno stack Onload eseguendo onload_stackdump:
```
onload_stackdump
```

Esegui il seguente script bash nel terminale. La funzione disable_single_queue esegue le seguenti operazioni:

Recupera l'napi_id corrispondente a una coda RX utilizzando netlink (ynl)
Imposta la proprietà threaded dell'napi_id su 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
}

Esegui il seguente comando per richiamare la funzione disable_single_queue:
```
disable_single_queue NIC_NAME QUEUE_ID
```
Sostituisci quanto segue:
- NIC_NAME: il nome del sistema operativo dell'interfaccia di rete, ad esempio ens8f0.
- QUEUE_ID: l'ID della coda recuperato in precedenza.

Recuperare lo stato del polling occupato di una coda

Per controllare lo stato NAPI di una coda e verificare se esegue il polling occupato, puoi utilizzare i seguenti comandi:

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)"'

Sostituisci quanto segue:

NIC_NAME: il nome del sistema operativo dell'interfaccia di rete, ad esempio ens8f0.
QUEUE_ID: l'ID della coda che vuoi controllare.
QUEUE_TYPE: rx o tx.

Ottimizzare le prestazioni

Questa sezione fornisce indicazioni generali per l'ottimizzazione delle prestazioni delle istanze bare metal U4 (U4P e U4C). Modifica gli esempi in queste indicazioni in base alle esigenze dei tuoi workload.

Esaminare la topologia NUMA per le istanze bare metal U4

La tabella seguente descrive quali interfacce di rete utilizzano quali nodi NUMA per le istanze bare metal U4:

NIC (Google Cloud nome)	NIC (nome sistema operativo)	Nodo NUMA	PCIE BDF
`nic0`	`enp22s0f0`	0	`0000:16:00.0`
`nic1`	`ens8f0`	0	`0000:27:00.0`
`nic2`	`ens48f0`	2	`0000:b8:00.0`

La tabella precedente include i nomi delle interfacce di rete assegnati dal sistema operativo per RHEL. I nomi effettivi potrebbero essere diversi.

Determinare uno schema di isolamento della CPU

Per ottenere prestazioni ottimali, ti consigliamo di isolare quanto segue:

Le CPU utilizzate dall'applicazione
Le CPU utilizzate per il polling occupato delle code RX Onload
Le CPU utilizzate per gli interrupt del kernel e dei driver

La tabella seguente fornisce un esempio di come isolare le CPU sulle istanze bare metal U4. Modifica il mapping in base alle esigenze dei tuoi workload, ad esempio potresti voler utilizzare più CPU per l'applicazione.

Finalità	CPU
Interrupt del kernel generali	0,1,30,31,60,61,90,91
Interrupt del driver `nic0` per le code 0-11	2
Interrupt del driver `nic1` per le code 0-11	3
Interrupt del driver `nic0` e `nic1` per le code 12-15	4
Polling occupato `nic1`	5-16
Thread dell'applicazione `nic1` (Onload)	17-29
Polling occupato `nic0`	32-43
Thread dell'applicazione `nic0` (Onload)	44-59
Interrupt del driver `nic2` per le code 0-11	62
Interrupt del driver `nic2` per le code 12-15	63
Polling occupato `nic2`	64-75
Thread dell'applicazione `nic2` (Onload)	76-89

Installare le dipendenze per l'ottimizzazione del rendimento

Per installare le dipendenze richieste per l'ottimizzazione del rendimento, esegui il seguente comando:

dnf -y install numactl tuna jq

Configurare i parametri di avvio del kernel

Per isolare le CPU dalla pianificazione del kernel, esegui il seguente comando. Inoltre, disattiva la tecnologia Intel QuickAssist (QAT) in modo che non interferisca con i core isolati.

Il seguente comando di esempio isola le CPU 2-29, 32-59 e 62-89 e designa 0,1,30,31,60,61,90,91 per gli interrupt del kernel generali. Questi valori corrispondono allo schema di isolamento della CPU di esempio. Sostituisci i valori in base alle esigenze a seconda dello schema di isolamento della CPU.

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

Configurare l'isolamento della CPU post-avvio

Per isolare le CPU dopo l'avvio, esegui il seguente comando. I valori corrispondono allo schema di isolamento della CPU di esempio. Sostituisci i valori in base alle esigenze a seconda dello schema di isolamento della CPU.

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

Assegnare gli interrupt delle code a CPU specifiche

Questa sezione descrive come spostare le richieste di interrupt delle code gve (IRQ) a CPU specifiche. Il driver gve viene utilizzato dal tipo di interfaccia di rete GVNIC in Google Cloud.

Determina gli IRQ per un determinato intervallo di code e interfacce di rete. Consulta il seguente esempio bash, che definisce una funzione 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 ','
}

Assegna gli IRQ alla CPU appropriata in base allo schema di isolamento della CPU. Lo script di esempio seguente utilizza tuna e la funzione irq_list del passaggio precedente:

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)"

Configurare le impostazioni del sistema operativo e del dispositivo

Esegui il seguente script per configurare le impostazioni che consentono di ridurre al minimo la latenza e impedire che i comportamenti predefiniti del sistema operativo interferiscano con le configurazioni di 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

Per indirizzare il traffico lontano dalle code dedicate ai workload Onload, utilizza RSS (ethtool -X). Lo script di esempio seguente si basa sui valori dello schema di isolamento della CPU di esempio. Poiché Onload utilizza le code 0-11, lo script indirizza tutto il resto del traffico alle code 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
```

Passaggi successivi

Per sincronizzare il clock di sistema dell'istanza con il clock della NIC fisica del suo server host, consulta Configurare l'ora esatta.

Utilizzare Onload

Informazioni su Onload

Prima di iniziare

Creare un'istanza U4

Connettersi all'istanza utilizzando SSH

Passare all'utente root

Configurare Onload

Installare le dipendenze

Recuperare l'origine Onload

Creare Onload

Disattivare il monitoraggio dei rami indiretti (IBT)

Caricare Onload

Caricare Onload su un'istanza U4P o U4C

Caricare Onload su un'istanza U4S

Configurare i flag Onload

Eseguire l'unload di Onload

Configurare un servizio systemd che avvia automaticamente Onload

Configurare il polling occupato

Recuperare la coda RX utilizzata da uno stack Onload

Attivare il polling occupato su una coda RX

Pianificare gli eventi di ricreazione dei thread

Disattivare il polling occupato su una coda RX

Recuperare lo stato del polling occupato di una coda

Ottimizzare le prestazioni

Esaminare la topologia NUMA per le istanze bare metal U4

Determinare uno schema di isolamento della CPU

Installare le dipendenze per l'ottimizzazione del rendimento

Configurare i parametri di avvio del kernel

Configurare l'isolamento della CPU post-avvio

Assegnare gli interrupt delle code a CPU specifiche

Configurare le impostazioni del sistema operativo e del dispositivo

Passaggi successivi

Configurare un servizio `systemd` che avvia automaticamente Onload