HFTKernel 7.2.11
Rede zero-copy mais robusta, filas de NIC ordenadas e hardware de tempo mais confiável
Base upstream: Linux 7.2.11. Alterações desde o Linux 7.2.10. Data de lançamento: 15 de outubro de 2026.
Propriedade de buffers AF_XDP do mlx5 mais robusta
O HFTKernel 7.2.11 fortalece o processamento de recepção zero-copy de AF_XDP em adaptadores NVIDIA mlx5.
Para filas de recepção com passos, as novas tentativas de reposição de MPWQE agora preservam o estado explícito de propriedade de cada buffer XSK. Se a alocação falhar temporariamente, uma nova tentativa posterior do NAPI não libera mais o mesmo quadro UMEM por meio de um ponteiro obsoleto.
O caminho de nova tentativa agora é idempotente:
- cada buffer XSK original é liberado uma única vez;
- as reposições parcialmente concluídas mantêm seu estado de propriedade;
- uma alocação bem-sucedida substitui o buffer e limpa o marcador de liberação;
- as tentativas posteriores atuam somente sobre os buffers que ainda precisam de substituição.
Uma execução upstream de pressão AF_XDP de 20 segundos exercitou 1,575,262 falhas de alocação de buffers sem descritores inválidos, erros de WQE nem avisos do kernel.
A fila de recepção cíclica legada recebe a mesma proteção de propriedade.
No teste upstream correspondente, foi oferecido tráfego UDP de 64 bytes a 12 Mpps. O caminho atualizado processou 356,904,225 pacotes em 30 segundos, incluindo 571,405 eventos xdp_rx_ring_full, sem erros de propriedade nem de dados.
Para o HFTKernel, isso fortalece a ingestão de dados de mercado de alta frequência, os manipuladores de feeds AF_XDP, os sistemas de distribuição de pacotes e as cargas de captura zero-copy sob pressão do anel de recepção.
Doorbells TX ordenados do Intel ICE
O driver Intel ICE volta a usar gravações MMIO ordenadas ao publicar doorbells das filas TX.
O driver primeiro atualiza a contabilização de Dynamic Queue Limits na memória normal e depois notifica a NIC de que novos descritores estão disponíveis. A gravação ordenada garante que a contabilização da fila esteja globalmente visível antes que o dispositivo possa concluir o trabalho transmitido.
Isso é especialmente importante em ARM64, em que writel_relaxed() não fornece a ordenação necessária entre memória normal e MMIO.
A alteração foi testada com um adaptador Intel E810-XXV sob carga de rede sustentada. O caminho ordenado manteve sincronizadas a conclusão da NIC e a contabilização da fila de software.
Para o HFTKernel, isso fortalece o processamento TX sustentado em hardware Intel compatível e preserva uma relação consistente entre o envio de descritores, a execução do hardware e a contabilização da conclusão.
Ordenação correta da conclusão de ICOSQ no mlx5
O driver mlx5 agora atualiza o doorbell da fila de conclusão antes de publicar o contador consumidor de ICOSQ.
Uma dma_wmb() mantém as duas operações ordenadas:
- O espaço de CQ é liberado para o dispositivo.
- O contador consumidor do software avança.
- O dispositivo observa a capacidade de conclusão atualizada antes do envio de trabalho adicional de controle interno.
Isso preserva o ciclo de vida da fila de conclusão e mantém alinhado entre o host e a NIC o processamento das filas de envio internas do mlx5.
Ciclo de vida AF_XDP mais confiável no Google GVE
O Google Virtual Ethernet DQO recebe um conjunto coordenado de melhorias no ciclo de vida zero-copy de AF_XDP.
Os buffers XSK agora são liberados quando um descritor de conclusão RX informa um erro. Os buffers enviados à NIC também são devolvidos quando os anéis RX são parados ou redefinidos.
O encerramento do conjunto XSK agora usa a variante correta de bloqueio NAPI quando as operações de gerenciamento de filas já mantêm o bloqueio netdevice. Isso permite que a reconfiguração das filas avance sem tentar adquirir o mesmo bloqueio duas vezes.
As alterações de parada de filas e do conjunto XSK abrangem cenários de produção observados em ambientes Google Cloud.
Para o HFTKernel Cloud, isso permite configuração, reconfiguração, reinício e desmontagem limpos de AF_XDP em interfaces GVE DQO.
Estimativa mais precisa do atraso PCIe no OCP PTP
O driver OCP PTP agora usa KTIME_MAX como limite superior inicial para estimar o atraso PCIe.
O máximo sem sinal anterior se tornava um valor negativo quando representado como ktime_t, o que impedia que atrasos reais medidos o substituíssem. O cálculo atualizado usa o domínio de tempo com sinal correto e mantém um ajuste válido da janela de marcas de tempo.
Isso melhora a compensação do atraso do caminho PCIe para placas de tempo OCP compatíveis e fortalece a relação entre a janela de marcas de tempo do host e a leitura do relógio de hardware.
Para o HFTKernel, isso oferece uma base de hardware de tempo mais limpa para sincronização PTP, correlação de marcas de tempo e medição de latency.
Estado de cpuset mais consistente durante alterações no ciclo de vida da CPU
O HFTKernel 7.2.11 inclui várias correções de cpuset relevantes para o posicionamento automatizado de CPU.
Durante as operações de desconexão de CPU, guarantee_active_cpus() agora considera o intervalo entre as alterações da máscara de CPUs ativas e a propagação das máscaras efetivas atualizadas de cpuset.
O modo de cgroup é avaliado enquanto cpuset_mutex está mantido, deixando sincronizados o estado da hierarquia e as atualizações de máscaras.
A verificação do modo v2 também usa um indicador estável dedicado em vez de ler um ponteiro para a raiz do cgroup que pode estar mudando.
Em conjunto, essas alterações fortalecem o estado de cpuset durante:
- a conexão a quente de CPU;
- as operações de montagem e revinculação de cgroups;
- as alterações no ciclo de vida dos serviços;
- o gerenciamento automatizado de partições de CPU.
Para o HFTKernel, isso permite separação confiável entre núcleos de negociação, núcleos de rede, CPUs de manutenção e cargas de serviços.
Processamento limitado do despejo de fluxos do Open vSwitch
Os despejos de fluxos netlink do Open vSwitch agora mantêm as metades inferiores desativadas durante cada callback limitado de despejo.
Antes, operações locais repetidas de ativação das metades inferiores podiam fazer a própria thread de despejo processar o acúmulo pendente de softIRQ. Em uma CPU ocupada com processamento de pacotes, esse acúmulo podia ser reposto continuamente.
O caminho atualizado mantém o callback limitado pelas entradas de fluxo incluídas na resposta netlink atual. O processamento de softIRQ de pacotes permanece nos caminhos normais de execução da rede em vez de ser absorvido pela thread de despejo de fluxos do plano de controle.
Para o HFTKernel Cloud e os perfis de rede virtualizada, isso cria uma separação mais clara entre a carga do caminho de dados e as operações de diagnóstico do plano de controle.
Configuração previsível de anéis io_uring
Os anéis SQ, CQ e de buffers fornecidos deixam de ser contabilizados contra RLIMIT_MEMLOCK, restaurando sua semântica de configuração estabelecida.
Isso evita que serviços comuns sem privilégios recebam um limite artificial do número de anéis por memória que já é controlada pelo ciclo de vida de io_uring e dos cgroups de memória.
O caso de reprodução upstream com anéis de 4,096 entradas voltou de 21 anéis para a configuração esperada de 64 anéis sob o limite memlock padrão de 8 MiB.
Para as regiões compostas de memória io_uring que de fato são contabilizadas, a contabilização agora inclui todas as páginas alocadas, incluindo páginas finais de arredondamento para potência de dois fora da região lógica solicitada.
Quando a alocação composta excederia o limite, io_uring pode recorrer a uma alocação em massa de tamanho exato.
Essa combinação oferece:
- criação previsível de SQ e CQ;
- criação previsível de anéis de buffers fornecidos;
- contabilização precisa das alocações compostas fixadas;
- melhor uso da memória perto dos limites configurados.
Contabilização correta da memória bloqueada e remapeada
MREMAP_DONTUNMAP agora preserva a contabilização consistente de locked_vm em dois casos adicionais.
VMAs anônimas bloqueadas que se fundiriam consigo mesmas permanecem separadas para que a origem e o destino mantenham seu estado correto de bloqueio.
Remapeamentos parciais de VMAs bloqueadas dividem o intervalo de origem antes de mover as tabelas de páginas, mantendo a contabilização alinhada com as páginas que permanecem na origem e as representadas pelo destino.
Para o HFTKernel, isso fortalece a contabilização do ciclo de vida da memória para aplicações que usam conjuntos de trabalho bloqueados junto com operações avançadas de remapeamento.
Análise mais confiável de AF_PACKET, Virtio, VLAN e GSO
Os caminhos de rede virtual e sockets de pacotes agora aplicam uma sequência consistente de análise de cabeçalhos.
Pacotes GSO marcados com VLAN enviados por AF_PACKET SOCK_RAW são analisados após a aplicação dos metadados de Virtio. Isso preserva as posições corretas dos cabeçalhos de rede e transporte e evita análise redundante.
Pacotes GSO apoiados por Virtio sempre passam pela análise de fluxo quando os metadados de descarga de checksum não fornecem a posição de transporte. Isso garante que:
- o protocolo de rede seja validado;
- o cabeçalho de transporte esteja presente nos dados lineares;
- o deslocamento de transporte seja inicializado;
- as opções IPv4 e os cabeçalhos de extensão IPv6 sejam tratados corretamente.
Os deslocamentos da análise de fluxo também são tratados corretamente para buffers de pacotes maiores que 64 KiB, incluindo BIG TCP e quadros grandes AF_PACKET PACKET_VNET_HDR. O caminho do analisador de fluxos BPF recebe a mesma proteção.
Para o HFTKernel, isso fortalece as cargas de captura e reprodução de pacotes, TUN/TAP, Virtio, classificação BPF e gateways virtuais.
Recepção TCP zero-copy mais robusta com memória de dispositivos
A recepção TCP zero-copy agora reconhece fragmentos net_iov não apoiados por páginas antes de solicitar indicações de mapeamento de páginas.
Isso abrange tanto a memória de dispositivos apoiada por DMA-BUF quanto os tipos net_iov de io_uring.
Dados legíveis apoiados por páginas ainda podem ser copiados ou mapeados normalmente. Quando o próximo fragmento pertence à memória de dispositivo, o kernel retorna a indicação correta de salto em vez de tratá-lo como uma página convencional.
Isso fortalece a interação entre recepção TCP zero-copy, memória de dispositivos, DMA-BUF e buffers de rede apoiados por io_uring.
Configuração mais segura de XDP e de separação de cabeçalho e dados TCP
Os dispositivos de rede agora reconhecem programas XDP de buffer único anexados por bpf_link ao decidir se a separação de cabeçalho e dados TCP pode ser ativada.
Assim, o kernel preserva a compatibilidade entre o programa XDP anexado e a disposição dos buffers de recepção da NIC, independentemente de o programa ter sido instalado pelo caminho legado ou pela API de links BPF.
O Veth também atualiza corretamente a capacidade de transmissão XDP do par após alterações na configuração GRO enquanto a interface está desativada, mantendo os caminhos de redirecionamento de contêineres e namespaces alinhados à configuração ativa do par.
Mapeamento IOMMU direto para recursos MMIO
Recursos MMIO com DMA_ATTR_MMIO agora ignoram o tratamento de buffers intermediários de SWIOTLB.
MMIO não pode ser copiado por meio de um buffer intermediário. O caminho atualizado passa diretamente ao mapeamento IOVA de IOMMU, incluindo recursos não alinhados à página.
Para o HFTKernel Hardware, isso fortalece o mapeamento de recursos de dispositivos e aceleradores atrás de uma IOMMU e remove um caminho intermediário incompatível da configuração de MMIO.
Proteção de invalidação TLB em AMD
O HFTKernel 7.2.11 detecta AMD TLBI Erratum #1718.
Nos processadores afetados, uma sequência INVLPGB e TLBSYNC pode não invalidar a entrada TLB pretendida. Quando não há microcódigo atualizado disponível, o kernel ativa uma solução alternativa de software.
Isso fortalece a correção das transições de espaço de endereços e da invalidação TLB em sistemas AMD compatíveis.
TX e recuperação PCIe mais robustos no Broadcom NetXtreme-E
O driver Broadcom bnxt_en agora mapeia o comprimento completo com preenchimento dos pacotes TX curtos.
Isso mantém o comprimento DMA alinhado ao tamanho do pacote apresentado ao hardware, incluindo quadros pequenos de controle transmitidos por interfaces VLAN e macvlan em adaptadores NetXtreme-E compatíveis.
A recuperação PCIe também restaura a configuração BAR de forma consistente tanto nos caminhos de redefinição fatais quanto nos não fatais. A visibilidade MMIO do dispositivo, o controle do barramento e a decodificação de memória são restabelecidos em ordem controlada após a recuperação.
Ferramentas de medição incluídas
O HFTKernel 7.2.11 inclui:
cpujitterPara intervalos sem execução de CPU, interferência do escalonador, atividade de IRQ e softIRQ e caudas de latency.
memjitterPara alocação, first-touch, conjuntos de trabalho bloqueados e comportamento sob pressão de memória.
irqjitterPara análise da atividade de IRQ e softIRQ.
Essas ferramentas conectam as alterações no kernel ao comportamento de toda a pilha de aplicações.
Resultado do HFTKernel 7.2.11
O HFTKernel 7.2.11 fortalece o sistema operacional ao redor das aplicações sensíveis à latency:
- as novas tentativas AF_XDP de mlx5 preservam a propriedade de UMEM sob pressão dos anéis e da alocação;
- o Google GVE gerencia buffers AF_XDP de forma consistente durante erros e eventos do ciclo de vida das filas;
- o Intel ICE publica o estado da fila TX antes de acionar o doorbell da NIC;
- o mlx5 mantém ordenadas as atualizações do espaço de conclusão com o avanço das filas internas de envio;
- as placas OCP PTP mantêm a compensação correta do atraso PCIe;
- o estado de cpuset permanece consistente durante alterações no ciclo de vida de CPU e cgroups;
- o Open vSwitch mantém o trabalho de despejo de fluxos separado de um acúmulo ilimitado de softIRQ;
- os anéis io_uring mantêm configuração previsível e contabilização precisa de memória;
- os caminhos AF_PACKET, Virtio, GSO, BIG TCP, XDP e TCP zero-copy recebem tratamento mais robusto de buffers e cabeçalhos;
- a invalidação TLB de AMD e o mapeamento MMIO de IOMMU recebem proteção específica do hardware.
Em conjunto, essas alterações oferecem uma base mais previsível e mensurável para HFT, dados de mercado, gateways de execução, redes na nuvem, processamento de pacotes e infraestrutura com marcas de tempo de hardware.