Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Trabaja con Onload

En esta página, se describe cómo usar Onload con instancias de Compute Engine U4.

Acerca de Onload

Onload es una pila de red de alto rendimiento para aplicaciones sensibles a la latencia que requieren latencia ultrabaja, fluctuación mínima y rendimiento coherente. Onload proporciona una implementación de TCP/IP que omite el kernel del sistema operativo y se ejecuta directamente en el espacio del usuario, mientras permite que las aplicaciones usen las APIs de socket BSD estándar.

El uso de Onload con la solución ULL incluye compatibilidad con lo siguiente:

Direccionamiento de flujo: Puedes omitir el hash de escalamiento del lado de recepción (RSS) predeterminado si diriges flujos de tráfico específicos directamente a una cola de recepción (RX) designada. Se admite el direccionamiento de flujo de 3 tuplas (protocolo, dirección IP de destino y puerto de destino).

Antes de comenzar

Antes de trabajar con Onload en instancias de Compute Engine U4, debes cumplir con los siguientes requisitos.

Crea una instancia de U4

Si aún no lo hiciste, crea una instancia de Compute Engine U4 con uno de los siguientes procedimientos que incluyen la configuración requerida para Onload:

Para crear una instancia de Bare Metal U4P o U4C, consulta Crea instancias de Compute Engine ULL.
Para crear una instancia de máquina virtual (VM) U4S, consulta Crea instancias de Compute Engine que no sean ULL para cargas de trabajo auxiliares.

Conéctate a tu instancia con SSH

Si aún no lo hiciste, conéctate a tu instancia con SSH.

Cambia al usuario raíz

Los comandos y las secuencias de comandos de los siguientes procedimientos modifican la configuración a nivel del sistema, los parámetros del kernel y las interfaces de red. Para ejecutarlos correctamente, debes hacerlo como usuario raíz. Puedes cambiar a un shell raíz ejecutando sudo su o agregar sudo antes de ejecutar los comandos según sea necesario.

Configura Onload

En esta sección, se describen los pasos necesarios para configurar Onload en una instancia de U4.

Instala dependencias

Si usas Rocky Linux, habilita el repositorio de CodeReady Builder (CRB). Si usas Red Hat Enterprise Linux (RHEL), omite este paso.
```
dnf -y config-manager --enable crb
```

Instala las dependencias requeridas para Onload:

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

Extrae la fuente de Onload

Para extraer el onload repositorio con los cambios requeridos, ejecuta los siguientes comandos:

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 -3
curl -L https://github.com/Xilinx-CNS/onload/pull/282.patch | git -C /usr/src/onload am -3
curl -L https://github.com/Xilinx-CNS/onload/pull/325.patch | git -C /usr/src/onload am -3
curl -L https://github.com/Xilinx-CNS/onload/pull/327.patch | git -C /usr/src/onload am -3

Compila Onload

Para compilar Onload, ejecuta los siguientes comandos:

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

Inhabilita el seguimiento de bifurcación indirecta (IBT)

Se debe inhabilitar IBT para usar Onload como se describe en Incompatibilidad del seguimiento de bifurcación indirecta (IBT) .

Para inhabilitar IBT, ejecuta los siguientes comandos:

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

Carga Onload

En esta sección, se describe cómo cargar Onload en tu instancia.

Carga Onload en una instancia de U4P o U4C

Para cargar Onload en una instancia de Bare Metal U4P o U4C, usa la siguiente secuencia de comandos.

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

Carga Onload en una instancia de U4S

Para cargar Onload en una instancia de VM U4S, usa la siguiente secuencia de comandos.

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

Reemplaza lo siguiente:

NIC_NAME: Es el nombre del SO de la interfaz de red, como enp22s0f0.
ALLOCATED_QUEUES: Es la cantidad de colas de recepción (RX) y transmisión (TX) que se asignarán a Onload en la interfaz de red. Establece este valor en la mitad de la cantidad total de colas RX o TX asignadas a la vNIC.

Para las instancias de U4S, el recuento total de colas (para las colas RX o TX, respectivamente) es igual a num_vcpus / num_vnics, hasta un máximo de 16 colas por vNIC. Por ejemplo, si la vNIC tiene 4 colas TX totales, establece este valor en 2. Si la vNIC tiene 16 colas TX totales, establece este valor en 8.

Para obtener más información sobre la asignación de colas predeterminada, consulta Colas de recepción y transmisión.

Configura las marcas de Onload

Para optimizar el rendimiento y ayudar a reducir la latencia, puedes usar el siguiente conjunto de variables de entorno y marcas cuando ejecutas tus aplicaciones con Onload. En esta sección, se incluyen parámetros de configuración recomendados que puedes ajustar según sea necesario para tus aplicaciones.

Debes especificar estos parámetros antes de los comandos de la aplicación. Por ejemplo, para ejecutar una aplicación con esta configuración, usa el siguiente 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

Descarga Onload

Para descargar Onload, usa la siguiente secuencia de comandos.

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

Configura un servicio `systemd` que inicie Onload automáticamente

Para iniciar Onload automáticamente cuando se inicia la instancia, puedes registrarlo como un systemd servicio. Crea un archivo de servicio con la siguiente plantilla:

[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

Reemplaza lo siguiente:

START_SCRIPT_PATH: Es la ruta de acceso a la secuencia de comandos que inicia Onload, como una de las secuencias de comandos en Carga Onload.
OPTIMIZATION_SCRIPT_PATH: Es la ruta de acceso a la secuencia de comandos opcional que aplica las configuraciones de optimización. Si lo deseas, puedes crear una secuencia de comandos que incluya las optimizaciones de rendimiento y agregarla aquí. De lo contrario, puedes quitar la línea que incluye esta variable.
STOP_SCRIPT_PATH: Es la ruta de acceso a la secuencia de comandos que detiene Onload, como la secuencia de comandos en Descarga Onload.

Configura el sondeo ocupado

En esta sección, se proporcionan ejemplos de cómo configurar el sondeo ocupado en tu instancia.

El sondeo ocupado verifica continuamente si hay paquetes de red nuevos en lugar de esperar las interrupciones del dispositivo, lo que ayuda a reducir la latencia y la fluctuación. Para obtener más información sobre el sondeo ocupado, consulta Sondeo ocupado en la documentación del kernel de Linux.

Obtén la cola RX que usa una pila de Onload

Para obtener la cola RX que usa una pila de Onload, haz lo siguiente:

Ejecuta onload_stackdump para obtener el ID de la pila de Onload:
```
onload_stackdump
```

Debido a que el ID de la pila de Onload y el ID de la cola de NAPI no siempre coinciden, usa la siguiente secuencia de comandos para obtener el nombre de la interfaz, el índice y el ID de la cola correspondientes de un ID de pila.

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)

Reemplaza ONLOAD_STACK_ID por el ID de la pila para la que deseas habilitar o inhabilitar el sondeo ocupado.

Registra los valores que se usarán cuando habilite o inhabilite el sondeo ocupado en las siguientes secciones.

Habilita el sondeo ocupado en una cola RX

En esta sección, se proporciona un ejemplo de cómo puedes habilitar el sondeo ocupado en una cola RX específica que usa una pila de Onload.

Ejecuta la siguiente secuencia de comandos Bash en tu terminal. La función enable_single_queue hace lo siguiente:

Obtiene el napi_id que corresponde a una cola RX con netlink (ynl).
Establece la propiedad threaded: busy-poll en el napi_id.
Obtiene el kthread_pid del subproceso que está sondeando el napi_id.
Usa taskset para vincular el kthread_pid a una CPU específica.

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
}

Ejecuta el siguiente comando para invocar la función enable_single_queue:
```
enable_single_queue NIC_NAME QUEUE_ID CPU_ID
```
Reemplaza lo siguiente:
- NIC_NAME: Es el nombre del SO de la interfaz de red, como ens8f0.
- QUEUE_ID: Es el ID de la cola que obtuviste antes.
- CPU_ID: Es el ID de la CPU en la que se ejecutará el subproceso de sondeo ocupado, como 5.
Asegúrate de planificar los eventos de recreación de subprocesos que podrían afectar la configuración de sondeo ocupado.

Planifica los eventos de recreación de subprocesos

Cuando el kernel vuelve a crear un subproceso, las configuraciones de subprocesos asociadas no persisten, como su máscara de afinidad de CPU y su política de programación. Los eventos como los siguientes hacen que el kernel vuelva a crear un subproceso que está sondeando NAPI:

Aleteos o restablecimientos de vínculos
Adjuntos de programas XDP (por ejemplo, cuando se ejecutan las secuencias de comandos para cargar Onload o adjuntar programas XDP personalizados)
Cambios en los parámetros de anillo (ethtool -G)
Cambios en el recuento de colas (ethtool -L)

Para evitar problemas, considera evitar las tareas que causan eventos de recreación de subprocesos durante las operaciones normales.

Para mantener la configuración de sondeo ocupado después de que se vuelva a crear un subproceso, debes obtener el nuevo ID de proceso (PID) del subproceso y volver a vincularlo a la CPU. Para ello, vuelve a ejecutar la enable_single_queue función again.

Inhabilita el sondeo ocupado en una cola RX

En esta sección, se proporciona un ejemplo de cómo puedes inhabilitar el sondeo ocupado en una cola RX específica que usa una pila de Onload.

Ejecuta onload_stackdump para obtener la cola RX que usa una pila de Onload:
```
onload_stackdump
```

Ejecuta la siguiente secuencia de comandos Bash en tu terminal. La función disable_single_queue hace lo siguiente:

Obtiene el napi_id que corresponde a una cola RX con netlink (ynl).
Establece la propiedad threaded del napi_id en 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
}

Ejecuta el siguiente comando para invocar la función disable_single_queue:
```
disable_single_queue NIC_NAME QUEUE_ID
```
Reemplaza lo siguiente:
- NIC_NAME: Es el nombre del SO de la interfaz de red, como ens8f0.
- QUEUE_ID: Es el ID de la cola que obtuviste antes.

Obtén el estado de sondeo ocupado de una cola

Para verificar el estado de NAPI de una cola y ver si está sondeando, puedes usar los siguientes comandos:

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

Reemplaza lo siguiente:

NIC_NAME: Es el nombre del SO de la interfaz de red, como ens8f0.
QUEUE_ID: Es el ID de la cola que deseas verificar.
QUEUE_TYPE: rx o tx.

Optimiza el rendimiento

En esta sección, se proporciona orientación general para optimizar el rendimiento de tus instancias de Bare Metal U4 (U4P y U4C). Ajusta los ejemplos de esta guía según sea necesario para tus cargas de trabajo.

Revisa la topología de NUMA para instancias de Bare Metal U4

En la siguiente tabla, se describe qué interfaces de red usan qué nodos NUMA para instancias de Bare Metal U4:

NIC (Google Cloud nombre)	NIC (nombre del SO)	Nodo NUMA	BDF de PCIE
`nic0`	`enp22s0f0`	0	`0000:16:00.0`
`nic1`	`ens8f0`	0	`0000:27:00.0`
`nic2`	`ens48f0`	2	`0000:b8:00.0`

En la tabla anterior, se incluyen nombres típicos de interfaces de red asignados por el SO para RHEL. Los nombres reales pueden ser diferentes.

Determina un esquema de aislamiento de CPU

Para obtener el mejor rendimiento, te recomendamos que aísles lo siguiente:

Las CPUs que usa tu aplicación
Las CPUs que se usan para sondear las colas RX de Onload
Las CPUs que se usan para las interrupciones del kernel y del controlador

En la siguiente tabla, se proporciona un ejemplo de cómo puedes aislar las CPUs en instancias de Bare Metal U4. Ajusta la asignación según sea necesario para tus cargas de trabajo. Por ejemplo, es posible que desees más CPUs de aplicación.

Objetivo	CPU
Interrupciones generales del kernel	0,1,30,31,60,61,90,91
Interrupciones del controlador `nic0` para las colas 0-11	2
Interrupciones del controlador `nic1` para las colas 0-11	3
Interrupciones del controlador `nic0` y `nic1` para las colas 12-15	4
Sondeo ocupado de `nic1`	5-16
Subprocesos de aplicación `nic1` (Onload)	17-29
Sondeo ocupado de `nic0`	32-43
Subprocesos de aplicación `nic0` (Onload)	44-59
Interrupciones del controlador `nic2` para las colas 0-11	62
Interrupciones del controlador `nic2` para las colas 12-15	63
Sondeo ocupado de `nic2`	64-75
Subprocesos de aplicación `nic2` (Onload)	76-89

Instala dependencias para la optimización del rendimiento

Para instalar las dependencias requeridas para la optimización del rendimiento, ejecuta el siguiente comando:

dnf -y install numactl tuna jq

Configura los parámetros de inicio del kernel

Para aislar las CPUs de la programación del kernel, ejecuta el siguiente comando. Esto también inhabilita la tecnología Intel QuickAssist (QAT) para que no interfiera con tus núcleos aislados.

El siguiente comando de ejemplo aísla las CPUs 2-29, 32-59 y 62-89, y designa 0,1,30,31,60,61,90,91 para las interrupciones generales del kernel. Estos valores corresponden al esquema de aislamiento de CPU de ejemplo. Reemplaza los valores según sea necesario según tu esquema de aislamiento de 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

Configura el aislamiento de CPU posterior al inicio

Para aislar las CPUs después del inicio, ejecuta el siguiente comando. Los valores corresponden al esquema de aislamiento de CPU de ejemplo. Reemplaza los valores según sea necesario según nuestro esquema de aislamiento de CPU.

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

Asigna interrupciones de cola a CPUs específicas

En esta sección, se describe cómo mover las solicitudes de interrupción (IRQ) de la cola gve a CPUs específicas. El controlador gve se usa con el tipo de interfaz de red GVNIC en Google Cloud.

Determina las IRQ para una interfaz de red y un rango de colas determinados. Consulta el siguiente ejemplo de Bash, que define una función 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 ','
}

Asigna IRQ a la CPU adecuada según tu esquema de aislamiento de CPU. La siguiente secuencia de comandos de ejemplo usa tuna y la función irq_list del paso anterior:

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

Configura el SO y los parámetros de configuración del dispositivo

Ejecuta la siguiente secuencia de comandos para configurar los parámetros que ayudan a minimizar la latencia y evitar que los comportamientos predeterminados del SO interfieran con tus configuraciones de 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

Para dirigir el tráfico lejos de las colas dedicadas a las cargas de trabajo de Onload, usa RSS (ethtool -X). La siguiente secuencia de comandos de ejemplo se basa en los valores en el esquema de aislamiento de CPU de ejemplo. Debido a que Onload usa las colas 0-11, la secuencia de comandos dirige todo el tráfico restante a las colas 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
```

Problemas conocidos

Consulta los siguientes problemas conocidos que pueden ocurrir cuando trabajas con Onload en instancias de U4:

Abrir y cerrar un socket puede tardar varios milisegundos. Este retraso se produce porque la configuración de direccionamiento de flujo requerida para AF_XDP es un proceso de ruta de control lento:
- Los operadores de intercambio que administran sockets de escucha pueden solucionar este problema con los parches que Google envió al repositorio de Onload ascendente (#335, #336). Asegúrate de incluir estos parches cuando extraigas la fuente de Onload.
- Los participantes de intercambio que establecen conexiones salientes no requieren los parches anteriores y, en su lugar, pueden usar la función EF_TCP_SHARED_LOCAL_PORTS existente de Onload para ayudar a reducir la latencia.

¿Qué sigue?

Para sincronizar el reloj del sistema de tu instancia con el reloj de la NIC física de su servidor host, consulta Configura la hora exacta.

Trabaja con Onload

Acerca de Onload

Antes de comenzar

Crea una instancia de U4

Conéctate a tu instancia con SSH

Cambia al usuario raíz

Configura Onload

Instala dependencias

Extrae la fuente de Onload

Compila Onload

Inhabilita el seguimiento de bifurcación indirecta (IBT)

Carga Onload

Carga Onload en una instancia de U4P o U4C

Carga Onload en una instancia de U4S

Configura las marcas de Onload

Descarga Onload

Configura un servicio systemd que inicie Onload automáticamente

Configura el sondeo ocupado

Obtén la cola RX que usa una pila de Onload

Habilita el sondeo ocupado en una cola RX

Planifica los eventos de recreación de subprocesos

Inhabilita el sondeo ocupado en una cola RX

Obtén el estado de sondeo ocupado de una cola

Optimiza el rendimiento

Revisa la topología de NUMA para instancias de Bare Metal U4

Determina un esquema de aislamiento de CPU

Instala dependencias para la optimización del rendimiento

Configura los parámetros de inicio del kernel

Configura el aislamiento de CPU posterior al inicio

Asigna interrupciones de cola a CPUs específicas

Configura el SO y los parámetros de configuración del dispositivo

Problemas conocidos

¿Qué sigue?

Configura un servicio `systemd` que inicie Onload automáticamente