Linux 7.3 lleva BIG TCP a los túneles VXLAN y Geneve, pero sus mantenedores no dan abasto ante la avalancha de parches generados con IA

La ventaja no se limita a redes con una MTU especialmente grande ni requiere necesariamente descarga de túneles en la tarjeta de red. También puede aplicarse a despliegues con MTU estándar y a equipos sin soporte de offload de túneles, ya que el software puede trabajar internamente con menos paquetes y de mayor tamaño.

Una serie de parches de soporte explica parte del trabajo necesario: las rutas de los túneles dejaron de asumir que la longitud de los paquetes sería inferior a 64 KiB o que cabría en campos de 16 bits. La serie cubre además cargas BIG TCP tanto para IPv4 como para IPv6 en VXLAN y Geneve.

Menos contención global de RTNL para las reglas FIB

Otro cambio importante reduce la dependencia del bloqueo global RTNL en operaciones de reglas de la FIB —la base de información de reenvío— como RTM_NEWRULE y RTM_DELRULE. La modificación apunta especialmente a sistemas que gestionan reglas de enrutamiento en muchos espacios de nombres de red, donde la serialización global puede limitar el paralelismo.

La evidencia disponible confirma el objetivo de mejorar la concurrencia, pero no aporta cifras fiables y precisas de aceleración para IPv4 o IPv6. Por tanto, cualquier porcentaje o multiplicador concreto iría más allá de los datos disponibles.

Nuevos controladores y mejoras de protocolos

La integración también amplía el soporte de hardware y de distintas capas de la red:

• El trabajo inalámbrico incorpora el controlador mm81x de Morse Micro para dispositivos S1G de largo alcance, además de un nuevo controlador NXPWIFI.
• La infraestructura preliminar Intel iXD está orientada a la función PIC del plano de control de Intel en IPU y FNIC Intel E2100 y posteriores.
• MPTCP mejora su comportamiento bajo una presión extrema de memoria, entre otras cosas mediante la poda de su cola de recepción de paquetes fuera de orden.
• El conjunto incluye más mejoras, correcciones y trabajo en controladores de red cableados e inalámbricos.

Estos cambios forman parte del código de red que entró en el trabajo de la ventana de integración de Linux 7.3. No deben confundirse con una versión estable de Linux 7.3 ya publicada.

Por qué los mantenedores dijeron estar “completamente desbordados”

Kicinski y Paolo Abeni informaron de que habían integrado 632 parches de net y 648 de net-next: 1.280 en total dentro de la integración de red. También advirtieron que esa cifra no reflejaba toda la carga de revisión. Su estimación, descrita como “rápida y aproximada”, fue que entre un tercio y la mitad de los parches de net-next parecían correcciones, limpiezas o aclaraciones de baja prioridad impulsadas por IA.

La presión llega en un contexto de crecimiento general de los envíos. En un periodo de nueve días, el subsistema recibió 405 publicaciones con la etiqueta

[PATCH net]

[PATCH net-next]

El problema no consiste únicamente en que la IA pueda producir código. Los colaboradores que recurren a estas herramientas también pueden generar a muy bajo coste explicaciones plausibles, informes de errores y solicitudes de revisión. Los mantenedores humanos siguen teniendo que determinar si cada cambio es necesario, correcto, seguro y suficientemente valioso como para incorporarlo al kernel.

Cómo quieren usar la IA durante la revisión

Los mantenedores afirmaron haber conseguido, con financiación de Meta, acceso y presupuesto para que varios modelos grandes de lenguaje revisen los parches. El objetivo inmediato es detectar algunos cambios alucinados o de baja calidad antes de que consuman más tiempo de revisión humana.

También planean orientar los modelos hacia tareas rutinarias del flujo de trabajo, como:

• gestionar las colas de Patchwork;
• dar indicaciones sobre problemas habituales del proceso de envío;
• editar mensajes de confirmación (commit messages); y
• posiblemente aplicar parches que ya cuenten con etiquetas de revisión de personas de confianza.

El planteamiento presenta los modelos de lenguaje como asistentes del flujo de trabajo, no como sustitutos de los mantenedores del subsistema. La diferencia es especialmente importante en el código del kernel sensible a la concurrencia. Los responsables señalaron rutas de eventos poco frecuentes, como errores y tiempos de espera de PCIe, donde las carreras dependientes del momento pueden ser difíciles de reproducir y aún más difíciles de demostrar como inexistentes. Una revisión mediante LLM puede ayudar a señalar patrones sospechosos, pero no puede establecer de forma fiable la corrección en todas las intercalaciones excepcionales.

Qué sigue sin saberse

La información disponible no indica las fechas previstas para

Linux 7.3-rc1

Del mismo modo, aunque las modificaciones de RTNL pretenden mejorar las operaciones paralelas de reglas FIB entre espacios de nombres de red, los materiales disponibles no permiten ofrecer una cifra exacta de rendimiento para IPv4 o IPv6. La conclusión prudente es arquitectónica: reducir la contención del bloqueo global debería dar más margen de escalabilidad a las cargas con una gestión muy paralela de espacios de nombres, pero el beneficio concreto dependerá de la carga de trabajo y de la configuración del sistema.