Linux 7.3 amplia o BIG TCP e reduz gargalos de rede — enquanto mantenedores enfrentam uma avalanche de patches gerados por IA

O merge de net-next-7.3 reuniu mudanças importantes no caminho de dados da rede e uma resposta incomum ao aumento do volume de patches produzidos com auxílio de inteligência artificial. A proposta dos mantenedores é usar vários modelos de fronteira na primeira rodada de revisão, mas manter a avaliação humana em problemas sutis de concorrência e recuperação de hardware. Essas alterações entraram durante a janela de merge; elas ainda não correspondem a uma versão estável do Linux 7.3.

BIG TCP chega aos túneis VXLAN e Geneve

O BIG TCP agora pode atravessar túneis UDP baseados em VXLAN e Geneve. Na prática, a pilha de rede consegue trabalhar internamente com cargas úteis superiores a 64 KiB e depois dividi-las com GSO/TSO, em vez de tentar transmitir pacotes desse tamanho diretamente pela rede física.

Nos testes informados com

netperf TCP_STREAM

• MTU padrão: de 34,44 para 39,56 Gbit/s, alta de 14,9%;
• Offload de hardware do túnel desativado: de 21,82 para 29,39 Gbit/s, alta de 34,7%.

No Geneve, o desempenho passou de 37,39 para 40,89 Gbit/s com MTU padrão, um ganho de 9,4%.

Esses números são específicos das configurações testadas e não representam uma promessa de aumento geral de velocidade para todo sistema com Linux 7.3. O resultado depende de fatores como gso_max_size e gro_max_size, recursos da placa de rede, estado dos offloads, MTU, tipo de túnel e carga de trabalho.

Menos contenção no bloqueio RTNL

Outra mudança importante afeta as regras da FIB — a base de informações usada pelo sistema para encaminhar pacotes. As operações IPv4 e IPv6 de adicionar e remover regras (RTM_NEWRULE e RTM_DELRULE) foram afastadas, quando possível, da serialização ampla imposta pelo RTNL, o bloqueio global associado à configuração de rede.

A proteção passou a usar mutexes por fib_rules_ops, uma estrutura mais específica para cada conjunto de regras. O RTNL ainda é necessário em alguns casos, incluindo o caminho de fib_unmerge() da primeira regra IPv4.

Em um teste sintético com 4.096 namespaces de rede, cada um recebendo 1.024 regras em paralelo, o tempo para IPv4 caiu de 22,752 para 0,918 segundo, uma aceleração de aproximadamente 24,8 vezes. No IPv6, a redução foi de 35,181 para 1,214 segundo, ou cerca de 29 vezes.

O cenário mede uma situação extrema de contenção em namespaces simultâneos. Portanto, não deve ser interpretado como uma previsão direta de desempenho para a inicialização normal de contêineres.

Mantenedores sobrecarregados por patches gerados com IA

O volume de contribuições também se tornou um dos assuntos centrais do ciclo. O mantenedor de redes Jakub Kicinski contabilizou 632 patches para net e 648 para net-next. Segundo sua estimativa, entre um terço e metade do net-next era formado por correções, limpezas ou esclarecimentos de baixa prioridade produzidos com auxílio de IA — algo entre 216 e 324 patches. Kicinski e Paolo Abeni afirmaram estar “completamente sobrecarregados”.

A resposta planejada não é simplesmente aceitar ou rejeitar o uso de IA. A Meta ofereceu orçamento e acesso a vários modelos de fronteira para revisar cada patch. A ideia é reduzir o risco de que um único modelo deixe passar alucinações ou erros sistemáticos.

A automação pode ser usada para tarefas como:

• gerenciar o Patchwork, ferramenta usada para acompanhar contribuições;
• fornecer comentários sobre problemas recorrentes de processo;
• editar mensagens de commit;
• eventualmente aplicar patches que já tenham sido revisados por pessoas de confiança.

Os mantenedores, porém, não consideram esse processo suficiente para caminhos raros e sensíveis a condições de corrida. Rotinas envolvendo erros e timeouts de PCIe, por exemplo, exigem que alguém examine o comportamento das APIs e a ordem correta da recuperação do hardware.

Novos drivers e outras mudanças de protocolo

O ciclo também inclui uma série de atualizações em drivers e protocolos:

• O suporte sem fio recebeu o driver inicial Morse Micro mm81x, para dispositivos USB e SDIO, além do novo driver NXPWIFI, da NXP. O trabalho relacionado a MLO — operação com múltiplos enlaces — também continuou.
• Na área cabeada, entrou o esqueleto inicial do driver Intel iXD, destinado ao suporte à função Control Plane PIC em IPUs/FNICs Intel E2100 e posteriores.
• Foram adicionados o suporte inicial a CXL para placas de rede AMD/Solarflare e o suporte à gravação de firmware em NICs AMD Pensando.
• O MPTCP passou a contar com um mecanismo de último recurso para podar filas de pacotes fora de ordem sob pressão extrema de memória. O objetivo é permitir recuperação e retransmissão, não melhorar o desempenho normal.
• No AF_UNIX, o uso de SCM_RIGHTS ganhou relatórios mais precisos quando um LSM rejeita determinados descritores de arquivo. Com SO_RIGHTS_NOTRUNC, o receptor pode identificar o descritor recusado e seu errno, em vez de perder o restante do vetor ao primeiro erro.

Quando o Linux 7.3 deve chegar?

A primeira versão candidata a lançamento, ou RC, era esperada para aproximadamente 30 de agosto de 2026. A versão estável estava projetada para o fim de outubro, caso o ciclo siga o cronograma habitual.

Usuários de distribuições com versões fixas provavelmente terão de esperar mais. Essas distribuições escolhem, adaptam, testam e publicam seus próprios kernels, em calendários diferentes do projeto principal. Distribuições rolling release podem empacotar o Linux 7.3 antes.

O CachyOS aparece como um possível candidato a adotá-lo cedo, mas as fontes disponíveis não indicam uma data confirmada. As imagens de agosto da distribuição ainda usavam o Linux 7.1.