Linux 7.3 acelera VXLAN e Geneve, reduz travamentos de roteamento e experimenta revisão com IA

São medições específicas de configuração. O resultado real depende de fatores como gso_max_size, gro_max_size, recursos da placa de rede, estado dos offloads, MTU, tipo de túnel e carga de trabalho. Quem administra uma infraestrutura com VXLAN ou Geneve deve medir o próprio ambiente antes de projetar o mesmo percentual de ganho.

Menos serialização RTNL nas regras de roteamento

Outra mudança reduz a dependência do bloqueio global RTNL nas operações de inserção e remoção de regras FIB IPv4 e IPv6. Sempre que possível, o trabalho passa a usar mutexes associados ao fib_rules_ops correspondente, permitindo que mais operações avancem em paralelo. O RTNL ainda é necessário em alguns casos, incluindo o caminho fib_unmerge() da primeira regra IPv4.

Um teste sintético mostra o potencial em cenários com gerenciamento intensivo de namespaces. A criação de 4.096 network namespaces, com 1.024 regras adicionadas a cada um em paralelo, caiu de 22,752 para 0,918 segundo no IPv4 — cerca de 24,8 vezes mais rápido — e de 35,181 para 1,214 segundo no IPv6, aproximadamente 29 vezes mais rápido.

Esses números medem uma situação extrema de disputa por bloqueios. Eles não significam que a inicialização comum de contêineres ou qualquer carga de roteamento ficará automaticamente 29 vezes mais rápida.

Por que os mantenedores estão recorrendo à IA

O subsistema de rede também virou um teste para o desenvolvimento de kernel assistido por IA. Jakub Kicinski informou a existência de 632 patches em net e 648 em net-next. Segundo sua estimativa, entre um terço e metade de net-next era formada por correções de baixa prioridade, limpezas ou esclarecimentos produzidos com ajuda de IA — algo entre aproximadamente 216 e 324 patches. Kicinski e Paolo Abeni descreveram a carga de trabalho como “completamente insustentável”.

A resposta proposta não é substituir os mantenedores por um único modelo. A Meta ofereceu orçamento e acesso a vários modelos de fronteira para que os patches recebam mais de uma revisão inicial. O objetivo é diminuir a chance de que uma alucinação ou interpretação equivocada de um modelo passe despercebida no processo.

A automação planejada inclui gerenciamento no Patchwork, comentários rotineiros sobre o processo, edição de mensagens de commit e, possivelmente, aplicação de patches que já tenham sido revisados por pessoas de confiança. Essas tarefas são mais estruturadas do que decidir se uma alteração está correta em um caminho raro de falha.

Essa diferença é crucial no kernel de rede. Condições de corrida incomuns e caminhos de recuperação de hardware — como erros de PCIe e tratamento de timeouts — ainda exigem análise humana. A IA pode filtrar trabalho repetitivo, mas não elimina a necessidade de compreender concorrência, contratos de API e a sequência correta de recuperação.

Novos drivers e melhorias de protocolo

O conjunto de alterações também inclui suporte inicial a hardware e protocolos:

• O driver inicial Morse Micro mm81x adiciona suporte a Wi-Fi HaLow em dispositivos USB e SDIO.
• O NXPWIFI chega como um novo driver sem fio da NXP, enquanto o trabalho em operação de múltiplos links continua.
• A Intel recebe o esqueleto inicial do driver iXD, voltado ao suporte de Control Plane PIC Function em IPUs e FNICs E2100 e posteriores.
• Na rede cabeada, entram suporte inicial a CXL para placas AMD/Solarflare e suporte à gravação de firmware em hardware AMD Pensando.

Também há mudanças menores, mas úteis. O MPTCP passa a contar com um mecanismo de último recurso para eliminar filas fora de ordem sob pressão extrema de memória. Trata-se de uma medida de recuperação para condições restritas, não de uma promessa de maior velocidade em uso normal.

No AF_UNIX, o envio de descritores de arquivo fica mais fácil de diagnosticar. Com SO_RIGHTS_NOTRUNC, o receptor pode identificar o descritor rejeitado e seu errno quando um LSM bloqueia um item específico de um vetor SCM_RIGHTS, em vez de perder o restante do vetor na primeira rejeição.

Quando o Linux 7.3 deve chegar aos usuários?

A primeira versão candidata do Linux 7.3 era esperada por volta de 30 de agosto de 2026, enquanto a versão estável estava projetada para o fim de outubro, caso o cronograma normal de desenvolvimento fosse mantido.

Isso não significa que servidores e desktops receberão esses recursos imediatamente. As distribuições escolhem suas versões de kernel, fazem backports de mudanças selecionadas, executam testes próprios e publicam atualizações em calendários diferentes. Distribuições de lançamento contínuo podem empacotar o kernel antes; aquelas com versões fixas podem levar bem mais tempo.

A CachyOS é uma possível adotante antecipada por seguir um modelo contínuo, mas as informações disponíveis sobre a edição de agosto mostram imagens usando Linux 7.1, sem confirmar uma data de adoção do Linux 7.3.

O que esse merge representa na prática

Para equipes de infraestrutura, as mudanças mais relevantes de imediato são o caminho BIG TCP para overlays e a redução da disputa durante o gerenciamento de regras em grandes volumes de network namespaces. Elas merecem atenção sobretudo em ambientes que combinam VXLAN ou Geneve com tráfego de alta vazão, ou que criam e configuram muitos namespaces simultaneamente.

Para desenvolvedores do kernel, o experimento de revisão com IA pode ser igualmente importante. O merge aponta para uma divisão prática de tarefas: modelos assumem triagem repetitiva e comentários procedurais, enquanto os mantenedores continuam responsáveis pelos casos incomuns — aqueles em que um patch aparentemente correto pode causar deadlock, tratar uma recuperação de hardware de forma errada ou violar uma regra implícita de sincronização.

O resultado é um conjunto robusto de novidades de rede a caminho do Linux 7.3. Antes que a maioria dos usuários possa depender delas, porém, ainda serão necessários testes com versões candidatas, validação em hardware e integração pelas distribuições.