Linux 7.3 acelera las redes superpuestas y prueba la revisión de parches con IA

La integración de la rama de redes de Linux 7.3 destaca por dos motivos muy distintos. Por un lado, busca mejorar el rendimiento de cargas de trabajo con redes superpuestas y muchos espacios de nombres. Por otro, muestra cómo los mantenedores intentan responder al creciente volumen de parches generados o asistidos por inteligencia artificial. El código llegó a la rama principal durante la ventana de integración del 20 de agosto de 2026, pero Linux 7.3 todavía no es un kernel estable.

BIG TCP llega a VXLAN y Geneve

La novedad más visible es la ampliación de BIG TCP a los controladores de túneles UDP VXLAN y Geneve. El kernel puede procesar internamente cargas superiores a 64 KiB y dividirlas mediante GSO y TSO antes de enviarlas por la red. La idea no es transmitir paquetes sobredimensionados, sino reducir el trabajo por paquete en las rutas de datos que atraviesan redes superpuestas.

Las pruebas publicadas con

netperf TCP_STREAM

• En VXLAN, el rendimiento pasó de 34,44 a 39,56 Gbit/s con MTU estándar: una mejora del 14,9 %.
• Con la descarga de hardware del túnel desactivada, VXLAN subió de 21,82 a 29,39 Gbit/s, un 34,7 %.
• Geneve pasó de 37,39 a 40,89 Gbit/s con MTU estándar, una mejora del 9,4 %.

Conviene poner estas cifras en contexto: son mediciones de una configuración concreta, no una promesa de que cualquier sistema Linux 7.3 será automáticamente más rápido. El resultado depende de parámetros como gso_max_size y gro_max_size, las capacidades de la tarjeta de red, el estado de las descargas de hardware, la MTU, el tipo de túnel y la carga de trabajo. Los operadores deberían medir su propia infraestructura VXLAN o Geneve antes de extrapolar esos porcentajes.

Menos contención al actualizar reglas de enrutamiento

Linux 7.3 también reduce la dependencia del bloqueo global RTNL al insertar y eliminar reglas de la FIB —la base de información de reenvío— tanto en IPv4 como en IPv6. Cuando es posible, las operaciones utilizan mutex asociados con el fib_rules_ops correspondiente, de modo que más tareas pueden avanzar en paralelo. RTNL sigue siendo necesario en determinados casos, incluido el recorrido fib_unmerge() de la primera regla IPv4.

Una prueba sintética ilustra el beneficio en escenarios con mucha paralelización: crear 4.096 espacios de nombres de red y añadir 1.024 reglas a cada uno en paralelo pasó de 22,752 a 0,918 segundos en IPv4, unas 24,8 veces más rápido. En IPv6, el tiempo bajó de 35,181 a 1,214 segundos, aproximadamente 29 veces.

Son resultados que reflejan una situación extrema de contención de bloqueos. No deben interpretarse como una mejora garantizada para el arranque habitual de contenedores ni para cualquier carga de enrutamiento.

La avalancha de parches con IA desborda a los mantenedores

El subsistema de redes se ha convertido además en un campo de pruebas para el desarrollo del kernel asistido por IA. Jakub Kicinski contabilizó 632 parches net y 648 parches net-next, y calculó que aproximadamente entre un tercio y la mitad de net-next correspondía a correcciones, limpiezas o aclaraciones de baja prioridad impulsadas por IA. Eso equivale a unos 216–324 parches. Kicinski y Paolo Abeni describieron la carga de trabajo como “completamente desbordados”.

La respuesta planteada no consiste en sustituir a los mantenedores por un único modelo. Meta aportó presupuesto y acceso a varios modelos de IA de vanguardia para que los parches reciban varias revisiones iniciales. El objetivo es reducir el riesgo de que una alucinación o una interpretación errónea de un modelo llegue al proceso sin ser detectada.

Entre las tareas que se quiere automatizar figuran la gestión de Patchwork, los comentarios rutinarios sobre el proceso, la edición de mensajes de commit y, potencialmente, la aplicación de parches que ya hayan sido revisados por personas de confianza. Son labores más estructuradas que decidir si un cambio es correcto en una ruta de error poco frecuente.

Esa diferencia es crucial en las redes del kernel. Los mantenedores subrayaron que las condiciones de carrera inusuales y las rutas de recuperación del hardware —por ejemplo, la gestión de errores PCIe y de tiempos de espera— todavía requieren una revisión humana minuciosa. La IA puede filtrar trabajo repetitivo, pero no elimina la necesidad de comprender la concurrencia, los contratos de las API ni el orden correcto de recuperación.

Nuevos controladores y mejoras de protocolos

La integración de redes también incorpora varias piezas de soporte para hardware y protocolos:

• El controlador inicial Morse Micro mm81x añade compatibilidad con dispositivos Wi‑Fi HaLow mediante USB y SDIO.
• NXPWIFI llega como nuevo controlador inalámbrico de NXP, mientras continúa el trabajo en operación multilink.
• Intel recibe el esqueleto inicial del controlador iXD, destinado a ofrecer soporte para la función Control Plane PIC en IPU y FNIC E2100 y posteriores.
• En redes cableadas se suma soporte inicial de CXL para NIC de AMD/Solarflare y la posibilidad de actualizar el firmware de hardware AMD Pensando.

También hay cambios más pequeños, pero prácticos. MPTCP incorpora un mecanismo de último recurso para recortar las colas de paquetes fuera de orden cuando la memoria está sometida a una presión extrema. Es una medida de recuperación para condiciones muy limitadas, no una promesa de mayor velocidad normal.

En AF_UNIX, el paso de descriptores de archivo resulta más fácil de diagnosticar. Con SO_RIGHTS_NOTRUNC, el receptor puede identificar qué descriptor fue rechazado y conocer su errno cuando un LSM bloquea un descriptor concreto dentro de un array SCM_RIGHTS, en lugar de perder el resto del array al producirse el primer rechazo.

¿Cuándo llegará Linux 7.3 a los usuarios?

La primera versión candidata de Linux 7.3 se esperaba alrededor del 30 de agosto de 2026, mientras que el lanzamiento estable se proyectaba para finales de octubre, siempre que el ciclo de desarrollo siguiera el calendario habitual.

Eso no significa que la mayoría de servidores y equipos de escritorio reciban estas funciones en octubre. Cada distribución selecciona su versión del kernel, decide qué cambios retroporta, realiza sus propias pruebas y publica las actualizaciones en fechas diferentes. Las distribuciones de actualización continua pueden empaquetarlo antes; las de versiones fijas suelen tardar bastante más.

CachyOS podría estar entre los primeros adoptantes por su modelo rolling, pero la información disponible sobre su lanzamiento de agosto muestra imágenes con Linux 7.1 y no confirma una fecha de adopción de Linux 7.3.

Qué cambia en la práctica

Para los equipos de infraestructura, las mejoras que más merece la pena vigilar son la ruta BIG TCP en VXLAN y Geneve y la menor contención al configurar reglas en grandes cantidades de espacios de nombres de red. Pueden resultar especialmente relevantes en entornos que combinan túneles superpuestos con tráfico de alto rendimiento o que crean y configuran muchos espacios de nombres simultáneamente.

Para quienes desarrollan el kernel, el experimento de revisión con IA puede ser igual de importante. La integración apunta a una división de tareas pragmática: los modelos absorben parte de la clasificación repetitiva y de los comentarios procedimentales, mientras los mantenedores conservan la responsabilidad sobre los casos poco comunes en los que un parche aparentemente correcto puede provocar un interbloqueo, gestionar mal una recuperación o romper una regla implícita de sincronización.

Linux 7.3 se encamina así a convertirse en una actualización de redes relevante, pero todavía necesita pruebas con versiones candidatas, validación en hardware e integración por parte de las distribuciones antes de que la mayoría de usuarios pueda depender de sus novedades.