SoftIRQ y procesamiento rápido de paquetes en una red Linux

SoftIRQ y procesamiento rápido de paquetes en una red Linux

He estado leyendo sobre el ajuste del rendimiento de Linux para obtener tiempos de procesamiento de paquetes más rápidos al recibir datos del mercado financiero. Veo que cuando la NIC recibe un paquete, lo coloca en la memoria a través de DMA y luego genera un HardIRQ, que a su vez establece algunas configuraciones de NAPI y genera un SoftIRQ. Luego, SoftIRQ usa controladores de dispositivo/NAPI para leer datos de los buffers RX mediante sondeo, pero esto solo se ejecuta durante un tiempo limitado (net.core.netdev_budget, predeterminado en 300 paquetes). Estas son en referencia a un servidor real que ejecuta ubuntu, con una NIC solarflare. Mis preguntas están a continuación:

  1. Si cada HardIRQ genera un SoftIRQ y el controlador del dispositivo lee varios paquetes de una vez (netdev_budget), ¿qué sucede con los SoftIRQ generados por cada uno de los paquetes que se drenaron del búfer RX de una sola vez (cada paquete recibido generará un disco duro)? y luego suave irq)? ¿Están estos en cola?

  2. ¿Por qué la NAPI utiliza sondeos para drenar el RX_buffer? El sistema acaba de generar un SoftIRQ y está leyendo el búfer RX, entonces ¿por qué el sondeo?

  3. Presumiblemente, el drenaje del RX_Buffer a través del softirq solo ocurrirá desde 1 RX_Buffer específico y no a través de múltiples RX_Buffers. Si es así, ¿aumentar el netdev_budget puede retrasar el procesamiento/drenaje de otros RX_buffers? ¿O se puede mitigar esto asignando diferentes RX_buffers a diferentes núcleos?

  4. Hay configuraciones para garantizar que los HardIRQ se generen y manejen de inmediato. Sin embargo, los SoftIRQ pueden procesarse más adelante. ¿Existen ajustes/configuraciones para garantizar que los SoftIRQ relacionados con la RX de red también se manejen con la máxima prioridad y sin demoras?

Respuesta1

En cuanto a la respuesta a la cuarta pregunta,

Sí, las tarjetas NIC de red son los periféricos asociados con softirq, ya que softirq es la máxima prioridad en todos los mecanismos de la mitad inferior.

Entonces, para prohibir el retraso que podría provocar la caída del paquete posteriormente, se utilizan softirqs.

Básicamente, el mecanismo NAPI también está destinado a manejar los paquetes que vienen con una velocidad que el kernel no puede manejar con el mecanismo de interrupción por algunas razones.

Yo sugeriría simplemente ir al capítulo de controladores de red en LDD3.Aquíes el enlace que puede ser útil para el mismo.

información relacionada