DPDK: cómo planificar correctamente el procesamiento de paquetes en el espacio de usuario

Principio básico del DPDK y clasificación correcta

DPDK Es un marco de trabajo para aplicaciones que deben procesar paquetes de red con la menor sobrecarga posible en el espacio de usuario. En lugar de seguir la ruta habitual a través de la pila de red del núcleo, los sockets y sus estructuras de paquetes, una aplicación puede utilizar directamente determinadas tarjetas de red para su propia ruta de datos. Esto está pensado sobre todo para lograr altas tasas de paquetes, bajas latencias y un procesamiento fácilmente planificable en el caso de muchos paquetes pequeños.

La expresión „sin límites del núcleo“ es una simplificación. El núcleo de Linux sigue estando presente para el sistema operativo, la gestión de la memoria, los procesos, la seguridad y numerosas tareas administrativas. DPDK tampoco sustituye los límites de la tarjeta de red, ni los del PCIe, ni los del ancho de banda de la memoria, ni los de la CPU. En el caso de las interfaces vinculadas, lo que hace principalmente es eludir la ruta de datos habitual del núcleo y trasladar el procesamiento de paquetes a una aplicación especializada.

En la ruta de red estándar de Linux, interactúan los controladores de red, NAPI, la gestión de paquetes y la capa de sockets. Esta ruta no se basa exclusivamente en interrupciones. Un DPDK-Controlador de modo de encuesta consulta las colas de recepción directamente desde el espacio de usuario. La aplicación recibe los paquetes en grupos, los comprueba o los modifica y, a continuación, los envía a una cola de envío o a una fase posterior de procesamiento.

No se trata de un ajuste general del núcleo y, en el caso de una aplicación web habitual con pocas conexiones TCP, no suele ser la primera medida a tomar. Solo cuando se demuestre que la propia ruta de datos de los paquetes está limitada —por ejemplo, en el caso de la distribución de carga en capa 4, el filtrado o los puntos finales de túnel—, la posible mejora justifica el esfuerzo operativo adicional. Las características dependientes de la versión deben contrastarse con la documentación de la etiqueta de versión concreta que se utilice; una versión candidata no es equiparable a una versión en producción.

Cómo funciona la ruta de paquetes del espacio de usuario

En la entrada, la aplicación configura una o varias colas Rx de la tarjeta de red. Un núcleo de ejecución asignado consulta una cola en un bucle y recibe una ráfaga de paquetes disponibles. Estos Procesamiento por ráfagas Reduce el número de llamadas a funciones y la carga administrativa por paquete. Tras la clasificación, el reenvío o la modificación, la aplicación almacena los paquetes de forma agrupada en una cola de transmisión (Tx-Queue).

El polling evita numerosos cambios de interrupción en la ruta de datos con alta carga de trabajo y hace que el trabajo de un núcleo sea más predecible. El precio a pagar es una CPU que permanece activa continuamente: incluso cuando la cola está vacía, el lcore sigue comprobando si hay nuevos paquetes. Por eso, este modelo se adapta mejor a una carga elevada constante que a interfaces con tráfico escaso o muy variable.

Los datos del paquete y los metadatos se encuentran en rte_mbuf-objetos. Estos proceden de un mempool creado previamente y contienen, por ejemplo, la longitud del paquete, el puerto de entrada, información de descarga y, en su caso, un hash RSS. Los pools reservados previamente, una asignación fija entre colas y núcleos y rutas de procesamiento cortas favorecen Localidad de la caché y evitamos estructuras de datos comunes innecesarias.

Sin embargo, «Zero Copy» no es una característica automática de DPDK. El hecho de que se copien datos, y dónde se copien, depende de la tarjeta de red (NIC), el controlador, las descargas y la lógica de la aplicación. Las tramas grandes o segmentadas pueden estar formadas por varios mbufs enlazados; esto es relevante, por ejemplo, en el caso de las tramas jumbo. Quien reformatee, combine o transfiera datos de paquetes entre búferes incompatibles debe tener en cuenta los posibles movimientos de memoria en su propia ruta de datos.

Arquitectura, recursos y límites estrictos

La capa de abstracción del entorno, abreviada EAL, inicializa DPDK y proporciona, entre otras cosas, la reserva de memoria, el acceso a dispositivos, temporizadores y la asignación de núcleos lógicos. Sobre esta base, la aplicación configura las colas de Ethernet, los mempools y su procesamiento. Un «lcore» es, en este contexto, un núcleo lógico asignado a DPDK, no simplemente un hilo de aplicación que se desplaza aleatoriamente. Estas características básicas de EAL se recogen aquí en la documentación de DPDK 25.07; los detalles específicos de cada versión deben comprobarse adicionalmente para la etiqueta de lanzamiento utilizada.

Para que la ruta de los datos sea lineal, a menudo un núcleo procesa un paquete en su totalidad: desde la recepción, pasando por la toma de decisiones, hasta el envío. Este modelo de «ejecución hasta el final» evita las transferencias entre núcleos. Por el contrario, una canalización separa, por ejemplo, el análisis sintáctico, la búsqueda de flujos y el reenvío en etapas. Puede organizar las responsabilidades, pero añade bucles, sincronización y, potencialmente, una peor localidad de memoria entre las etapas.

La planificación también debe tener en cuenta la arquitectura NUMA. En la medida de lo posible, la cola, el lcore y los grupos de paquetes deberían ubicarse en el mismo nodo NUMA, para que la ruta de datos no tenga que acceder con frecuencia a la memoria de otro zócalo de CPU. Además, el rendimiento alcanzable depende de las funciones de la tarjeta de red, la conexión PCIe, el ancho de banda de la memoria, la frecuencia de la CPU, el tamaño de los paquetes y la complejidad de cada decisión sobre los paquetes.

Un equilibrador de carga L4 puede evaluar rápidamente la información de IP y puertos con DPDK, asignar flujos y reenviar paquetes. Sin embargo, esto no acelera automáticamente la terminación de TLS, los estados NAT complejos, el registro, las comprobaciones de estado o los backends lentos. Del mismo modo, el plano de control necesita tiempo de CPU disponible para la configuración, la telemetría y la gestión de errores. Por lo tanto, DPDK acelera una ruta de datos claramente delimitada, pero no necesariamente el servicio en su totalidad.

El tamaño y la vida útil de los búferes de paquetes también forman parte de la arquitectura. Los mempools limitan el número de búferes disponibles al mismo tiempo, mientras que la aplicación debe gestionar correctamente los cambios de propiedad. Los mempools con un tamaño demasiado reducido pueden agotarse bajo carga; las reservas excesivas consumen memoria. El tamaño adecuado viene determinado por las colas, los tamaños de ráfaga, la ruta de los paquetes y los picos de carga previstos, y no por una norma universal.

Comprobar los requisitos previos a la aplicación de DPDK

El DPDK solo se puede planificar cuando el hardware, la memoria y la asignación de la CPU encajan entre sí. Una simple instalación no basta para crear una ruta de datos eficaz: el PMD debe ser compatible con el modelo concreto de NIC, y debe ser posible reservar recursos para la aplicación. La siguiente comprobación distingue entre los requisitos técnicos mínimos y las suposiciones que solo se aplican al dispositivo realmente utilizado.

Las «hugepages» son la opción habitual para conjuntos de paquetes de gran tamaño, pero no son un requisito imprescindible para todas las aplicaciones DPDK. El EAL también admite la opción –no-huge. Este modo especial no es una recomendación estándar equivalente: antes de la fase piloto, deben comprobarse la idoneidad, la gestión de la memoria y las limitaciones del controlador. Los fundamentos del sistema y de EAL utilizados aquí se documentan en DPDK 25.07; comprueba además que las opciones coincidan con la versión realmente instalada.

Especialmente crítica es la Vinculación de dispositivos. Muchos PMD requieren que la NIC en cuestión se desconecte del controlador habitual del núcleo y, por ejemplo, se conecte a vfio-pci se asigna. La interfaz ya no estará disponible de forma habitual para la pila de red normal de Linux. Sin embargo, el procedimiento concreto debe ajustarse al PMD y no puede aplicarse de forma generalizada a todas las tarjetas de red compatibles.

Los PMD bifurcados constituyen una excepción importante. La documentación del controlador indica que dichos PMD no deben desvincularse del controlador del núcleo correspondiente. De este modo, el controlador del núcleo puede permanecer vinculado mientras una ruta de datos del espacio de usuario utiliza determinados recursos. La documentación enlazada, sin especificar versión, corresponde al estado de desarrollo 26.11.0-rc1 y no es una guía específica para la versión 26.07. Consulta la compatibilidad con los dispositivos y las herramientas del núcleo disponibles en el manual del PMD concreto que se utilice.

Antes de realizar cualquier cambio, la siguiente consulta de estado proporciona un inventario de los dispositivos PCI y su asignación actual de controladores. La consulta en sí misma no modifica ninguna asignación. Ejecútala en el sistema de destino utilizando la ruta correspondiente a la estructura de código fuente o de herramientas de DPDK instalada.

./usertools/dpdk-devbind.py --status

El acceso a la gestión de planes y la ruta de datos productivos deben estar separados, incluso si el PMD seleccionado no sustituye al controlador del núcleo. La accesibilidad mediante SSH o consola no debe depender de una interfaz cuya asignación o distribución de tráfico se modifique durante la fase piloto. Una interfaz de gestión independiente, un acceso fuera de banda o una ruta de rescate local previamente comprobada limitan el riesgo de una configuración errónea.

Comparación entre DPDK, AF_XDP y Kernelstack

La elección de la ruta de datos no es una clasificación, sino una decisión operativa. La pila del núcleo de Linux, AF_XDP y DPDK modifican, cada uno a su manera, la carga de trabajo, el acceso a los dispositivos y el consumo de CPU. La opción adecuada depende de si lo que realmente limita el rendimiento es la tasa de paquetes o la latencia en la ruta de red, o si el cuello de botella lo constituyen la aplicación, el cifrado y los backends.

AF_XDP es una opción intermedia para equipos que desean procesar los paquetes de forma anticipada y, al mismo tiempo, mantenerse fieles al modelo de red de Linux. El núcleo describe un modo de copia, así como el modo «zero copy», que requiere compatibilidad por parte del controlador. Si se solicita expresamente el modo «zero copy», la creación del socket puede fallar si el controlador no ofrece esta capacidad. Para comprender mejor el nivel XDP, resulta útil el artículo XDP y eXpress Data Path.

DPDK, por su parte, utiliza controladores en modo poll y procesa las colas directamente desde la aplicación. Esto permite eludir las partes relacionadas con los sockets y las interrupciones en la ruta de datos de DPDK, pero exige asumir la responsabilidad de la memoria, las colas y la asignación de núcleos. Zero Copy Esto no constituye ni una promesa general de rendimiento ni una característica automática de cualquier ruta DPDK; las copias dependen de la aplicación, las descargas y las transferencias de memoria.

Elige la pila del kernel si el enrutamiento, el cortafuegos, la observabilidad y la facilidad de uso son más importantes que una ruta de paquetes especializada. Considera AF_XDP si buscas una aceleración específica con conexión al núcleo. DPDK solo resulta rentable si existe una necesidad real de alta tasa de paquetes o latencia constante, si hay compatibilidad con las tarjetas de red (NIC) y si se cuenta con un equipo capaz de asumir de forma permanente la responsabilidad operativa adicional.

Planificar adecuadamente las colas, la asignación fija de la CPU y NUMA

Una resistente Asignación de colas Comienza con la proximidad entre la NIC, la CPU y la memoria. El EAL permite seleccionar núcleos lógicos, reservar memoria y asignar dispositivos. Para una ruta de datos sencilla, suele ser recomendable asignar de forma fija una cola Rx a un lcore, crear el mempool correspondiente en el nodo NUMA local y, a continuación, transferir el procesamiento a una cola Tx adecuada. Esta información básica sobre EAL está documentada en la documentación de DPDK 25.07 y, en el caso de las opciones que dependen de la versión, debe verificarse con la etiqueta de lanzamiento utilizada.

Un ejemplo no específico de un producto de un host con dos nodos NUMA sería el siguiente: la tarjeta de red del nodo 0 recibe dos colas de recepción (Rx); cada lcore del nodo 0 procesa una cola en su totalidad. Los búferes de paquetes también se encuentran en el nodo 0. Otro núcleo, que no realiza sondeos, queda libre para tareas administrativas, mientras que el nodo 1 se destina a otros servicios o a rutas de datos claramente separadas.

• Ruta de datos: un lcore asignado de forma fija a cada cola, pools de memoria locales y pares Rx/Tx claramente identificados.
• Administración: mantener libre capacidad de la CPU para telemetría, lógica de control, eventos y servicios del sistema operativo.
• Reserva: hay que prever capacidad para picos de carga, resolución de incidencias y ampliaciones previstas, en lugar de asignar todos los núcleos de forma permanente.

No compartas una cola Rx entre varios lcores. La guía del PMD desaconseja dividir las colas Rx y Tx, ya que los bloqueos globales necesarios para ello pueden afectar considerablemente al rendimiento. El acceso simultáneo de varios lcores a una cola Tx solo está previsto como excepción documentada si el controlador tiene la capacidad de RTE_ETH_TX_OFFLOAD_MT_LOCKFREE indica. Comprueba esta capacidad para la combinación concreta de NIC y PMD; no la deduzcas ni a partir de la velocidad del puerto ni de un conmutador de descarga general.

Un proceso con etapas separadas de análisis, clasificación y envío puede aclarar las responsabilidades. El enfoque de proceso documentado transfiere los paquetes a otros núcleos a través de anillos; esto genera accesos adicionales a la memoria y transferencias. Para filtros sencillos o el reenvío L4, el método «run-to-completion» por cola suele ser más fácil de planificar. Solo se deben utilizar varias etapas cuando la división del trabajo justifique el esfuerzo adicional en el perfil de carga concreto.

También Descargas de hardware No deben tenerse en cuenta en la planificación. Las funciones de suma de comprobación, segmentación, RSS o flujo disponibles dependen de las capacidades del dispositivo Ethernet concreto y de su PMD. Compruébalas antes del diseño y trata la ausencia de descarga como un caso normal de planificación, no como una excepción.

Supervisar de forma segura el funcionamiento del DPDK

El funcionamiento de una ruta de datos DPDK requiere métricas que tengan en cuenta tanto el procesamiento de paquetes como los recursos. Registra, como mínimo, los paquetes procesados, descartados y con errores, así como los valores propios de la aplicación relativos a las tasas de procesamiento, las reservas del mempool y Distribución de la latencia en lugar de un único valor medio. Los contadores adicionales de puertos, colas o controladores disponibles dependen del PMD concreto, de la NIC y de la aplicación, y deben comprobarse para la combinación utilizada.

El sondeo (polling) supone un conflicto de objetivos deliberado. Un lcore consulta continuamente su cola Rx para que los paquetes puedan procesarse sin pasar por la ruta de interrupciones habitual. Sin embargo, cuando hay poco o ningún tráfico, el bucle de sondeo permanece activo. Por lo tanto, además de los lcores de la ruta de datos, hay que prever capacidad de CPU para la lógica de control, la telemetría y el sistema operativo. La documentación de EAL utilizada como complemento se refiere a DPDK 25.07; las funciones dependientes de la versión deben comprobarse en la versión instalada.

Para el análisis de las causas, es importante la correlación temporal. Si la pérdida de paquetes se produce al mismo tiempo que el aumento de los contadores de errores, la disminución de las reservas del mempool o la saturación de la ruta de datos lcore, se trata, en un primer momento, de indicios que pueden comprobarse, pero aún no constituyen una prueba clara de la causa. Los tiempos de respuesta variables pueden estar relacionados, entre otras cosas, con la memoria alejada de NUMA, tareas concurrentes o traspasos de pipeline. Compara estas hipótesis con la asignación de núcleos, la distribución de colas y los valores medidos en el mismo intervalo de tiempo.

Un registro rápido en la interfaz no equivale a un registro completo y sin pérdidas de paquetes a largo plazo. Para las estadísticas de flujo o el análisis de encabezados, pueden bastar unos pocos metadatos. Si se desea almacenar cada paquete, el ancho de banda de almacenamiento, el volumen del búfer, el rendimiento de escritura y el soporte de almacenamiento elegido limitan además la estructura. La protección de datos y las normas de conservación son requisitos independientes que el rendimiento de la red no resuelve.

Planifica las máquinas virtuales y los contenedores como una tarea de integración independiente. Aclara, para la plataforma concreta, cómo se proporcionan el acceso a los dispositivos, el almacenamiento, la asignación de CPU y los permisos necesarios. Comprueba esta combinación con el PMD utilizado, en lugar de aplicar los parámetros de ejemplo de forma generalizada. La guía de Linux enlazada corresponde actualmente a la versión de desarrollo 26.11.0-rc1; para una instalación en producción, es determinante la documentación de la versión realmente instalada.

Comprobar sistemáticamente los fallos típicos

La búsqueda de errores debe empezar por diferenciar los síntomas observables de las posibles causas. No modifiques al mismo tiempo la asignación de controladores, el número de colas y los parámetros de memoria, ya que, de lo contrario, ya no será posible identificar el factor desencadenante. Los contadores no destructivos, la información sobre la configuración y una comparación entre la cola afectada y la no afectada suelen proporcionar, antes de intervenir, las pistas más fiables.

Si observas un comportamiento anómalo en la cola, comprueba quién es el propietario de la cola y el nodo NUMA del mempool. En el modelo «run-to-completion», el lcore asignado se encarga de la recepción, el procesamiento y el envío; una canalización transfiere los paquetes a otros núcleos. No obstante, no dividas la cola de recepción (Rx) entre lcores. El acceso simultáneo a una cola de transmisión (Tx) solo es posible si se ha notificado RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-Se prevé esta capacidad como una excepción. Un bloqueo auto-completado hace que compartir colas no sea la estrategia de escalabilidad recomendada.

Cuando no hay descargas de hardware, la pregunta correcta no es solo qué opción se ha activado, sino qué capacidades ofrecen realmente el dispositivo y el PMD. Una aplicación puede planificar una función deseada sin que esta esté disponible para ese modelo. Compara la compatibilidad de la tarjeta de red concreta con las capacidades notificadas en tiempo de ejecución antes de hacer que la ruta de datos dependa de esa descarga.

Los resultados de testpmd deben considerarse como una referencia o una prueba de funcionamiento, no como una demostración del rendimiento de la aplicación posterior. En el modo de reenvío de E/S, los paquetes se reenvían sin modificaciones, sin evaluar su contenido para su procesamiento técnico. Este modo no tiene en cuenta los analizadores sintácticos, las tablas de flujo, el NAT, el cifrado ni el estado del protocolo. La documentación enlazada, sin especificar la versión, corresponde a la 26.11.0-rc1; comprueba el comportamiento en el manual de la versión instalada. Anota el modo de reenvío, el tamaño de los paquetes, el número de colas Rx/Tx y los núcleos de reenvío, y repite la comparación con la lógica de procesamiento real.

Implementación, mantenimiento de versiones y decisión de puesta en marcha

Empieza con una prueba aislada y un perfil de carga: Tamaños de los paquetes, carga máxima, número de flujos y pasos de procesamiento necesarios. Comprueba la NIC concreta, junto con el controlador de modo de sondeo adecuado y las funciones necesarias, consultando la lista oficial de hardware y la matriz de controladores. El mero hecho de que un fabricante figure en la lista no garantiza ni todas las tarjetas ni todas las descargas. A continuación, realiza pruebas con lógica de aplicación real, no solo con un ejemplo de reenvío.

Anota la versión de DPDK, el firmware, los controladores, el núcleo y la configuración para cada prueba. Antes de realizar una actualización, lee las notas de la versión correspondientes a la etiqueta de lanzamiento concreta que se vaya a utilizar y documenta qué cambios son relevantes para tu propia ruta de datos. Las notas de la versión de otras versiones no sustituyen a esta asignación, ya que las funciones y las limitaciones pueden variar de una versión a otra.

Un punto concreto a tener en cuenta de las notas de la versión de DPDK 26.07 es el cambio en el algoritmo de vaciado y rellenado de la caché del mempool: desde entonces, su tamaño efectivo se corresponde con el tamaño configurado; anteriormente era un 50 % mayor. Solo cuando cada lcore de un mempool se limite exclusivamente a extraer objetos o a devolverlos, las notas de la versión recomiendan duplicar el tamaño configurado de la caché para evitar una posible duplicación de la tasa de fallos de caché. Esto afecta, por ejemplo, a las tuberías con lcores Rx y Tx separados, no de forma generalizada a las de «run-to-completion». El cambio afecta a la versión 26.07; la página histórica de la versión enlazada se encuentra ahora dentro de la documentación de la versión 26.11.0-rc1.

Empieza con una prueba piloto limitada y criterios de interrupción bien definidos. Compara el rendimiento, los percentiles de alta latencia, la pérdida de paquetes y el consumo de CPU en las mismas condiciones que las del funcionamiento actual. Comprueba la supervisión, los reinicios y la vuelta a la configuración anterior. Ten en cuenta los costes operativos; de ellos no se puede deducir una garantía general de rendimiento.

La implementación de DPDK resulta rentable sobre todo cuando los beneficios medidos justifican el esfuerzo adicional de mantenimiento. Para situarlo en el contexto de la plataforma del sistema circundante, el artículo añade El núcleo de Linux en el ámbito del alojamiento web La planificación. En el caso de los servicios de alojamiento habituales, mantén también la ruta de red existente como referencia en la prueba.