Linux 7.3 amplia o BIG TCP enquanto patches gerados por IA pressionam a equipe de rede

O benefício relatado também pode aparecer em redes com MTU padrão e em sistemas sem suporte de hardware para aceleração de túneis. Isso ocorre porque o software consegue processar internamente uma quantidade menor de pacotes maiores.

Uma série de patches de suporte detalha o trabalho necessário para tornar isso possível: vários caminhos de túnel precisaram deixar de presumir que os pacotes teriam menos de 64 KiB ou que seus tamanhos caberiam em campos de 16 bits. A série contempla cargas IPv4 e IPv6 do BIG TCP em VXLAN e Geneve.

Menos contenção global no RTNL para regras FIB

Outra mudança reduz a dependência do bloqueio global RTNL em operações de regras da FIB, como RTM_NEWRULE e RTM_DELRULE. O objetivo é ajudar sistemas que alteram regras de roteamento em vários namespaces de rede, nos quais um ponto único de serialização pode limitar o paralelismo.

As informações disponíveis confirmam a intenção de melhorar a concorrência, mas não fornecem números confiáveis e precisos de ganho para benchmarks IPv4 ou IPv6. Portanto, qualquer porcentagem ou multiplicador específico iria além das evidências disponíveis.

Novos drivers e melhorias em protocolos

O pull request de rede também amplia o suporte a hardware e aprimora diferentes camadas do subsistema:

• O trabalho de redes sem fio inclui o driver mm81x, da Morse Micro, voltado a dispositivos S1G de longo alcance, além de um novo driver NXPWIFI.
• A infraestrutura preliminar do Intel iXD mira a função PIC do plano de controle da Intel em IPUs e FNICs Intel E2100 e posteriores.
• O MPTCP passa a lidar melhor com situações de pressão extrema de memória, inclusive podando sua fila de recebimento fora de ordem.
• O conjunto inclui ainda outras melhorias, correções e atualizações para drivers com e sem fio em diferentes áreas do subsistema de rede.

Essas mudanças fazem parte do código de rede incorporado ao trabalho da janela de merge do Linux 7.3. Isso não significa que o Linux 7.3 estável já tenha sido lançado.

Por que os mantenedores disseram estar “completamente sobrecarregados”

Kicinski e Paolo Abeni relataram ter integrado 632 patches da árvore net e 648 da net-next — 1.280 patches ao todo — no pull request de rede. Eles também alertaram que essa contagem não representa toda a carga de revisão. Em uma estimativa “rápida e superficial”, de um terço à metade dos patches da net-next parecia ser formada por correções, limpezas ou esclarecimentos de baixa prioridade conduzidos por IA.

A pressão faz parte de um aumento mais amplo nas submissões. Em um período de nove dias, o subsistema recebeu 405 mensagens marcadas como

[PATCH net]

[PATCH net-next]

O problema não é apenas a capacidade da IA de escrever código. Colaboradores que usam IA também conseguem produzir explicações plausíveis, relatos de bugs e pedidos de revisão a um custo muito baixo. Ainda cabe aos mantenedores humanos decidir se cada alteração é necessária, correta, segura e merece ser incorporada.

Como a IA deve entrar no processo de revisão

Os mantenedores afirmaram ter conseguido acesso e orçamento financiados pela Meta para usar vários modelos de linguagem de grande porte na revisão de patches. A meta imediata é identificar algumas alterações alucinadas ou frágeis antes que elas consumam ainda mais tempo de revisão humana.

A equipe também pretende direcionar os modelos para tarefas rotineiras do fluxo de desenvolvimento, incluindo:

• administrar filas do Patchwork;
• apontar problemas comuns no processo de submissão;
• editar mensagens de commit; e
• possivelmente aplicar patches que já tenham recebido etiquetas de revisão de pessoas confiáveis.

A proposta trata os LLMs como assistentes de fluxo de trabalho, e não como substitutos dos mantenedores do subsistema. Essa diferença é especialmente importante em código de kernel sensível à concorrência. Os mantenedores destacaram caminhos de eventos raros, como erros e tempos limite de PCIe, nos quais condições de corrida dependentes de temporização podem ser difíceis de reproduzir ou de provar que não existem. A revisão por LLM pode ajudar a localizar padrões suspeitos, mas não consegue estabelecer de forma confiável a correção de todas as interações incomuns.

O que ainda não foi informado

As fontes fornecidas não indicam datas esperadas para o Linux 7.3-rc1 nem para a versão estável final. Elas descrevem mudanças de rede incorporadas durante o ciclo de desenvolvimento do 7.3, não um calendário oficial de lançamento.

Da mesma forma, embora as alterações no RTNL tenham como objetivo melhorar as operações paralelas de regras FIB em vários namespaces de rede, o material disponível não sustenta um número exato de desempenho para IPv4 ou IPv6. A conclusão segura é arquitetural: menos contenção em um bloqueio global deve dar mais espaço para escalar em cargas altamente paralelas de gerenciamento de namespaces, mas o ganho depende da carga de trabalho e da configuração do sistema.