El principio de ethtool e ideas para resolver problemas de pérdida de paquetes de tarjetas de red

Anteriormente registré la práctica de lidiar con problemas de pérdida de paquetes causados ​​​​por interrupciones suaves debido a una carga excesiva de tráfico de la tarjeta de red LVS y la práctica de ajustar el rendimiento de múltiples colas de las tarjetas de red RPS y RFS. personas, es práctico bajo baja presión. La probabilidad de encontrarlo no es alta. Esta vez, el tema que quiero compartir son las ideas de solución de problemas para la pérdida relativamente común de paquetes de la tarjeta de red del servidor. Si desea obtener más información sobre las soluciones a la pérdida de paquetes punto a punto, puede consultar el artículo anterior. "Cómo utilizar MTR para diagnosticar problemas de red". Para Linux, la herramienta de análisis de pérdida de paquetes de tarjetas de red más utilizada es, naturalmente, ethtool.

22 de junio de 2020: primer borrador

Primer borrador

Lea el texto original: práctica de ajuste del rendimiento de colas múltiples de NIC RPS y RFS, para la mayoría de usuarios en situaciones estresantes La probabilidad observada en la operación real dadas las circunstancias. Consulte la página de manual para obtener más detalles.

ethtool se utiliza para ver y modificar los parámetros del controlador y la configuración del hardware de los dispositivos de red, especialmente los dispositivos Ethernet cableados. Puede cambiar los parámetros de la tarjeta Ethernet según sea necesario, incluidos los parámetros de negociación automática, velocidad, dúplex y reactivación en LAN. Al configurar una tarjeta Ethernet, su computadora puede comunicarse de manera eficiente en la red. Esta herramienta proporciona una gran cantidad de información sobre los dispositivos Ethernet conectados a su sistema Linux.

Recibir paquetes de datos es un proceso complejo que involucra muchos detalles técnicos subyacentes, pero generalmente incluye los siguientes pasos:

Después de que la NIC recibe el paquete de datos, primero necesita sincronizar los datos. al kernel, el puente en el medio es el búfer de anillo rx. Es un área compartida por la NIC y el conductor. De hecho, el búfer del anillo Rx no almacena los datos del paquete real, sino el descriptor que apunta a su dirección de almacenamiento real. El proceso específico es el siguiente:

Cuando la velocidad de procesamiento del controlador no puede seguir el ritmo de la NIC. recepción A la velocidad de los paquetes, el controlador no puede asignar el búfer a tiempo y los paquetes recibidos por la NIC no se pueden escribir en sk_cache a tiempo. Si los paquetes de datos recibidos por la tarjeta de red no se pueden escribir en sk_buffer a tiempo, se producirá una acumulación. Cuando el búfer interno de la tarjeta de red esté lleno, algunos datos se descartarán, lo que provocará la pérdida de paquetes de datos. Esta parte de la pérdida de paquetes es rx_fifo_errors, que se refleja en el crecimiento del campo quince en /proc/net/dev y el crecimiento del indicador de desbordamiento en ifconfig.

En este punto, el paquete se ha movido a sk_buffer. Como se mencionó anteriormente, este es un búfer asignado en la memoria por el controlador y escrito a través de DMA, que escribe los datos directamente en la memoria sin depender de la CPU, lo que significa que el kernel en realidad no sabe que hay nuevos datos en la memoria. . datos. Entonces, ¿cómo se le hace saber al kernel que han llegado nuevos datos? La respuesta son las interrupciones, que le dicen al núcleo que han llegado nuevos datos y que es necesario seguirlos.

Hablando de interrupciones, se trata de interrupciones duras e interrupciones suaves. Primero debe comprender brevemente la diferencia entre las dos:

Después de que la NIC copia el paquete en el búfer del kernel a través de sk_buffer. DMA, la NIC iniciará inmediatamente una interrupción de hardware. Una vez que la CPU recibe el paquete, primero ingresará a la primera mitad del proceso. Después de que la CPU recibe el paquete, primero ingresará a la parte superior del controlador de interrupciones correspondiente a la interrupción de NIC (es parte del controlador de NIC), luego iniciará la interrupción suave e ingresará a la segunda mitad del controlador de interrupciones para comenzar a consumir. Los datos en sk_buffer se pasan a la pila del kernel para su procesamiento.

A través de interrupciones, las solicitudes de datos de NIC se pueden responder rápida y rápidamente, pero si la cantidad de datos es grande, se generará una gran cantidad de solicitudes de interrupción y la CPU estará ocupada procesando las interrupciones la mayoría de las veces. el tiempo, lo cual es muy ineficiente.

Para resolver este problema, el kernel y el controlador ahora utilizan un método llamado NAPI (Nueva API) para el procesamiento de datos. Su principio puede entenderse simplemente como interrumpir el sondeo. Cuando la cantidad de datos es grande, una interrupción pasa por el sondeo. La consulta regresa después de recibir una cierta cantidad de paquetes de datos para evitar múltiples interrupciones.

(1) Errores de RX

Indica el número total de errores de paquetes, incluidos errores de trama demasiado larga, errores de desbordamiento del búfer de anillo, errores de suma de comprobación CRC, errores de sincronización de trama, límite de exceso de quince y paquete de detección perdida, etc.

(2) Errores de RX

Indica el número total de errores de paquetes.

(2) Descarte de RX

Indica que el paquete ingresó al búfer de anillo, pero fue descartado cuando se copió a la memoria debido a razones del sistema, como memoria insuficiente.

(3) Desbordamiento de RX

Indica desbordamiento de quince. Esto se debe a que el IO transferido por el búfer en anillo (también conocido como cola del controlador) excede el número que el kernel puede manejar. El búfer en anillo es un búfer que existe antes de que se inicie la solicitud IRQ. Obviamente, el aumento en el desbordamiento significa que los paquetes de datos son descartados por la capa física de la placa antes de llegar al búfer de anillo, y la incapacidad de la CPU para manejar interrupciones es también una de las razones por las que el búfer de anillo está lleno. Los problemas anteriores se deben a la distribución desigual de ambos interruptores (ambos están presionados en core0) y la falta de afinidad resulta en la pérdida de paquetes.

(4) Cuadro RX

Representa un cuadro desalineado.

Los paquetes en la línea son primero recogidos por la NIC, que verifica la suma de verificación CRC del paquete para garantizar la integridad y luego elimina el encabezado del paquete para obtener la trama. La NIC verificará la dirección MAC de destino en el paquete MAC y la descartará si no coincide con la dirección MAC de esta NIC (excepto en modo promiscuo).

La NIC copia la trama al búfer FIFO interno de la NIC y activa una interrupción de hardware. (Si está utilizando una NIC de búfer de anillo, parece que el marco puede existir en el búfer de anillo antes de activar la interrupción del software (el próximo artículo explicará en detalle la dirección de los marcos en Linux), el búfer de anillo es la NIC y el controlador * *** Lo disfruta, es la memoria en el dispositivo, pero es visible para el sistema operativo. Como podemos ver en el código fuente del kernel de Linux, el controlador de la tarjeta de red usa kcalloc para asignar espacio, por lo que el búfer circular generalmente está allí. es un límite superior, además del tamaño de este búfer de anillo, debe ser el número de fotogramas que se pueden almacenar, no el tamaño en bytes. Además, el comando ethtool en algunos sistemas no puede cambiar el parámetro de anillo para establecer el tamaño del búfer de anillo. , aún no sé el motivo, tal vez el controlador no lo admita).

El controlador de NIC construye sk_buff, copia el marco de la NIC FIFO a la memoria skb y luego lo entrega al kernel, que lo maneja a través del controlador de interrupciones duras. (Las NIC que admiten napi deben colocarse directamente en el búfer de anillo sin activar interrupciones duras, y usar interrupciones suaves directamente para copiar los datos en el búfer de anillo y luego entregarlos directamente a la capa superior para su procesamiento. Cada NIC se puede procesar en una única interrupción suave (se procesan tramas PESO durante la interrupción)

Durante este proceso, el chip NIC realiza un filtrado MAC en las tramas para minimizar la carga del sistema.

El controlador NIC agrega un encabezado MAC de 14 bytes al paquete IP, formando una trama (aún sin CRC) que contiene las direcciones MAC del remitente y del receptor, que pueden ser El controlador crea el encabezado MAC con un entrada aleatoria, que también puede ser una dirección de enmascaramiento de host.

El controlador copia la trama en un búfer dentro del chip NIC (aún sin CRC) y luego es procesado por la NIC.

El chip NIC encapsula la trama incompleta (CRC faltante) en un paquete que se puede enviar nuevamente, es decir, agrega información de sincronización de encabezado y suma de verificación CRC, y luego lo descarta en la línea, completando una IP. El paquete se envía y puede ser visto por todas las NIC conectadas a la línea.

Cada dispositivo que genera una interrupción tiene un controlador de interrupción correspondiente, es decir, un controlador de dispositivo. Cada NIC tiene un controlador de interrupciones que notifica a la NIC que se ha recibido una interrupción y copia el paquete del búfer de la NIC a la memoria.

Cuando la NIC recibe un paquete de la red, necesita notificar al kernel que el paquete ha llegado. La NIC emite una interrupción inmediatamente. El kernel ejecutará la función de manejo de interrupciones registrada por la tarjeta de red. El controlador de interrupciones inicia la ejecución, notifica al hardware, copia los últimos paquetes de red en la memoria y luego lee más paquetes de la NIC.

Estas son tareas importantes, urgentes y relacionadas con el hardware. El kernel a menudo necesita copiar rápidamente paquetes de red en la memoria del sistema porque el tamaño del búfer en la NIC para recibir paquetes de red es fijo y mucho más pequeño que la memoria del sistema. Por lo tanto, si la replicación se retrasa, el búfer FIFO de la NIC se desbordará: los paquetes entrantes llenarán el búfer de la NIC y los paquetes posteriores se descartarán, lo que debería ser el motivo del desbordamiento en ifconfig.

Una vez que el paquete de red se copia en la memoria del sistema, la tarea interrumpida se completa y el control regresa al programa que se estaba ejecutando antes de la interrupción.

El búfer del kernel en la NIC está ubicado en la memoria de la PC y está controlado por el kernel. La NIC tiene un búfer FIFO o búfer en anillo, que debe distinguirse del FIFO, que es más pequeño que el kernel. buffer Si hay datos en el buffer, se intentará retener los datos en el buffer del kernel.

El búfer en la tarjeta de red no es espacio del kernel ni espacio del usuario. Es un búfer de hardware que permite el almacenamiento en búfer entre la placa y el sistema operativo.

El búfer del kernel está ubicado en el espacio del kernel, en la memoria, y es utilizado por los programas del kernel para almacenar en el buffer lecturas o escrituras de datos del hardware;

El búfer del usuario se encuentra en el espacio del usuario, en la memoria, y los programas del usuario lo utilizan para almacenar en el búfer los datos leídos o escritos desde el hardware.

Además, para acelerar el proceso; procesamiento de datos De forma interactiva, los buffers del kernel se pueden utilizar para almacenar en buffer los datos leídos o escritos en el hardware.

Además, para acelerar la interacción de datos, el búfer del kernel se puede asignar al espacio del usuario para que el programa del kernel y el programa del usuario puedan acceder a esta área al mismo tiempo.

Para las NIC con un búfer en anillo, el búfer en anillo está controlado por el controlador y la NIC, por lo que el kernel puede acceder directamente al búfer en anillo, generalmente copiando una copia de la trama en su propio espacio del kernel. Procesamiento (pasar las tramas al protocolo de capa superior y luego pasarlas una a una por el puntero skb).

Las tramas se pasan hasta que el usuario obtiene los datos, por lo que para una NIC con búfer en anillo, se producen muchas copias a medida que la trama pasa del búfer en anillo a la memoria de la computadora controlada por el núcleo).

La NIC funciona en la capa de enlace de datos (capa de enlace de volumen de datos) y realiza algunas sumas de verificación para encapsularla en marcos. Podemos mirar la suma de verificación en busca de errores y determinar si hay un problema con la transmisión. Luego se juzga desde el nivel del software si la pérdida de paquetes de datos se debe a que el búfer es demasiado pequeño.

Una máquina suele recibir alertas de pérdida de paquetes. Primero verifique si hay algún problema en la capa inferior:

(1) Verifique si el modo de trabajo es normal.

> (2 ) Compruebe si la prueba es normal

Si no hay problemas con la velocidad, dúplex, CRC, etc., entonces básicamente se puede descartar la interferencia de la capa física.

¿Por qué ethtool -S incrementa rx_crc_errors en la salida del contador de recepción?

Compruebe la salida de ethtool -S para encontrar las ubicaciones de caídas y errores.

Muestra el tipo de interfaz, modo de conexión, velocidad, etc. de p1p1, y si hay un cable de red actualmente conectado (si es un cable de red, los puertos admitidos mostrarán TP, si es fibra óptica, mostrará Fibra). Las siguientes son tres claves importantes: Tome la palabra como ejemplo

Puertos admitidos: [FIBRA]

Velocidad: 10000 Mb/s.

Compruebe la salida de ethtool -S para encontrar las ubicaciones de caídas y errores.

Análisis de errores de solicitud de ping

Explicación detallada del comando ifconfig

Explicación detallada del comando ethtool

ethtool resuelve el grave problema de pérdida de paquetes de tarjeta de red y su principio de funcionamiento

ethtool es la mejor manera de resolver el problema.