O pacing de pacotes em hardware no Linux 7.4 é chato, e esse é o ponto

Qual mudança do Linux 7.4 vai importar mais daqui a dois anos: a que transforma uma etapa da inicialização de minutos em milissegundos, ou um novo atributo em dispositivos de rede que a maioria das pessoas nunca vai ver? Nossa aposta é na segunda. É sem graça, mas daquele tipo de sem graça que costuma envelhecer bem.

O que chegou, em dois parágrafos

Como informa o Phoronix, o código central de rede do Linux 7.4 ganha offload de pacing em hardware, incluindo um novo atributo "pacing_offload" para dispositivos de rede. A ideia é entregar à NIC ou à SmartNIC o controle do ritmo e do espaçamento dos pacotes de saída, tarefa que até agora o próprio kernel executava. O driver IDPF é o primeiro a implementar o recurso.

A série de patches, que aparece no LWN assinada por Willem de Bruijn, do Google, descreve o recurso como a ativação de um offload de pacing "seguro" em hardware em um primeiro dispositivo, com suporte a rtnetlink para que administradores controlem a função, além de uma pequena otimização do offload de FQ. A janela de integração do 7.4 ainda está aberta, e um relato aponta para um lançamento no fim de dezembro.

Os grandes ganhos são o lugar errado para olhar

O Linux 7.4 tem vários itens chamativos. Um relato cita uma operação de memória na inicialização caindo de cerca de 268 segundos para 50 milissegundos. Outro fala em uma melhoria de até 265 vezes no FAT32. Rendem boas manchetes, e não duvidamos que sejam reais. Mas correções pontuais como essas funcionam eliminando um caso patológico. Você aproveita uma vez, e depois acabou.

O offload de pacing é de outra espécie. Ele não conserta nada quebrado. Ele passa uma tarefa recorrente para um hardware feito para isso. Todo pacote que sai de uma máquina ocupada precisa ser espaçado com critério, e fazer isso por software custa tempo de CPU a cada envio. Transferir isso para a NIC gera retorno proporcional ao tráfego que você move, e não ao azar que você tem.

Por que vemos isso como uma história de data centers de IA

Uma ressalva antes: nada do material que vimos diz que esse trabalho foi motivado por cargas de IA. Essa conexão é interpretação nossa. Mas faz sentido. Grandes clusters movimentam volumes enormes de dados entre máquinas, e nesse ambiente os ciclos de CPU gastos com a temporização de pacotes são ciclos que não servem a nada útil. Descarregar para a NIC é o caminho natural.

Também é revelador que o primeiro driver compatível seja o IDPF, de uma única família de dispositivos, e que o recurso seja exposto como uma chave controlada pelo administrador, e não como uma mudança global. É uma engenharia cautelosa e gradual. Achamos que é o jeito certo: provar em um dispositivo, dar aos operadores uma forma de ativar e deixar que outros sigam.

O outro lado é uma limitação real. Como diz uma manchete, é pacing de pacotes em hardware "se a sua NIC suportar". Por enquanto, a maioria dos leitores não verá mudança nenhuma. Quem usa um notebook ou um servidor doméstico comum não ganha nada hoje. Offloads em hardware historicamente chegam de forma desigual, e os drivers de outros fabricantes é que definirão se este se tornará comum ou continuará uma opção de nicho.

Quem ganha e o que fazer

Ganham os operadores de grandes redes com hardware compatível e o próprio Linux, que mantém sua posição de plataforma padrão para esse tipo de infraestrutura. Perdem, possivelmente, todos os que ainda acham que o progresso do kernel se mede por recursos de manchete.

Nosso conselho é modesto. Se você opera hardware baseado em IDPF em larga escala, acompanhe o lançamento do 7.4 e teste o atributo antes de ativá-lo em qualquer lugar que importe. Todos os outros podem arquivar isso tranquilamente em "coisas que acontecem debaixo do assoalho". Só acrescentaríamos que é debaixo do assoalho que vai sair boa parte do desempenho da próxima década.