Linux prepara suporte a Jumbo Frames de 9 KB para redes MediaTek de 10 GbE Sexta revisão de patches amplia o limite de MTU do driver MediaTek MT7988 e ajusta o gerenciamento de memória; testes com implementação equivalente alcançaram 9,87 Gbit/s.
A comunidade de desenvolvimento do kernel Linux avalia a sexta revisão de uma série de patches que introduz suporte a Jumbo Frames de aproximadamente 9 KB nas interfaces Ethernet 10 GbE do processador MediaTek MT7988. Enviada pelo desenvolvedor Sandeep Haemoon na madrugada de 14 de novembro de 2026, a proposta altera o driver mtk_eth_soc, que até então limitava o MTU (Maximum Transmission Unit) a 2.030 bytes.
O MT7988 é o hardware central de roteadores avançados e equipamentos de rede focados em alto desempenho. A nova implementação tem como objetivo permitir que interfaces XGMII compatíveis processem quadros Ethernet maiores, recurso frequentemente ativado em redes locais de alta velocidade para reduzir a carga de processamento do equipamento.
Por que o driver MediaTek estava limitado a quadros menores?
Em redes Ethernet convencionais, o tamanho padrão de MTU é de 1.500 bytes. O driver atual do MT7988 no kernel oficial do Linux consegue lidar com quadros ligeiramente maiores, anunciando um limite de 2.030 bytes. Esse valor, no entanto, é insuficiente para os tradicionais Jumbo Frames, frequentemente configurados na faixa de 9.000 bytes.
A restrição ocorria porque o hardware e o sistema de alocação de memória do driver não estavam devidamente parametrizados para prover buffers contínuos grandes o suficiente no caminho de recepção de pacotes. Sem o espaço garantido, o driver se recusava a aceitar e anunciar capacidades de MTU superiores.
O que muda no driver mtk_eth_soc?
A série técnica resolve a limitação em três etapas distintas, ajustando desde o manuseio de endereços em memória até os registros físicos do controlador Ethernet.
Correção de endereços DMA
O primeiro patch corrige um comportamento inconsistente no caminho de liberação de descritores de recepção. Durante a avaliação de código automatizada, percebeu-se que endereços DMA de 36 bits poderiam ser devolvidos ao hardware preservando equivocadamente os bits superiores de um buffer previamente utilizado.
O próprio desenvolvedor apontou que não conseguiu reproduzir essa falha em execuções reais, o que a classifica como uma correção técnica de manutenção. A modificação é independente dos Jumbo Frames, mas organiza a gestão de endereços para as novas implementações.
Seleção de buffers de recepção
O segundo patch adapta a infraestrutura interna de alocação de memória. O kernel utiliza um mecanismo conhecido como page_pool para reservar rapidamente espaço de memória para pacotes de rede. O desafio é que o page_pool opera sob limites específicos e não atende nativamente o tamanho de buffer exigido por quadros de 9 KB em sua configuração direta neste driver.
A alteração passa a verificar o tamanho requerido pelo anel de recepção. Quando a necessidade supera o limite suportado pelo mecanismo padrão, o driver aciona um caminho alternativo de alocação de memória do sistema, preparando terreno para os quadros pesados.
Habilitação da capacidade MTK_NETSYS_RX_9K
A principal funcionalidade encontra-se no terceiro patch. O código introduz a bandeira MTK_NETSYS_RX_9K, permitindo que o driver anuncie um limite de MTU de até 9.194 bytes nas portas XGMII compatíveis.
Para viabilizar a mudança, a proposta modifica os registros de controle do controlador, incluindo o XMAC_RX_CFG2 e o PDMA RX SDL, além de redimensionar os buffers compartilhados de recepção. O limite divulgado de 9.194 bytes refere-se estritamente ao MTU, mas a implementação já prevê fisicamente o espaço adicional ocupado pelos cabeçalhos Ethernet normais e pelas tags VLAN 802.1Q.
Teste com roteador BPI-R4 Pro 8X alcança 9,87 Gbit/s
O autor relatou resultados de testes de velocidade realizados com a ferramenta iperf3 em ambiente local de 10 GbE.
O ensaio foi conduzido em um roteador BPI-R4 Pro 8X, gerenciado pelo MediaTek MT7988. A conexão foi estabelecida pela porta lan6 conectada ao componente MxL86252, mantendo o MTU de 9.000 bytes nas duas pontas.
Um detalhe técnico essencial reportado: os resultados físicos não foram extraídos testando a exata versão v6 enviada agora para o kernel 7.3. Os números foram obtidos a partir de uma implementação funcional equivalente, adaptada (backport) sobre a base do Linux 6.18.60.
O relatório apresenta a seguinte vazão:
Foram registrados também envios bem-sucedidos de pacotes ICMP de aproximadamente 8 KB. Embora os números apontem para uma altíssima eficiência de rede e menor fragmentação, os resultados servem como validação técnica da lógica de programação, e não como benchmark universal para toda topologia de rede utilizando o MT7988.
Jumbo Frames também exigem mais memória
A viabilidade dos quadros gigantescos cobra um pedágio direto em hardware. Para armazenar os dados com segurança, a nova rotina precisará alocar as requisições em páginas de memória de 16 KiB.
Na arquitetura de anéis de recepção detalhada pelo desenvolvedor, o driver manterá aproximadamente 64 MiB de memória RAM continuamente alocada durante toda a operação ativa do mecanismo DMA. Trata-se de uma característica de desenho estrutural para assegurar a velocidade, não de um vazamento de memória. Contudo, em roteadores embarcados que costumam possuir capacidades modestas de RAM, esse consumo contínuo precisa ser calculado com atenção.
Novo suporte possui limitações com XDP e alterações de MTU
Os administradores de rede enfrentarão duas restrições conhecidas caso a proposta seja implementada dessa forma.
A primeira incompatibilidade afeta os usuários do XDP (eXpress Data Path), ferramenta focada em inspecionar e manipular pacotes na camada inferior da pilha de rede. O driver bloqueia sumariamente o carregamento de programas XDP nas interfaces se elas utilizarem anéis de recepção com buffers incompatíveis com os limites estruturais do page_pool.
A segunda restrição refere-se a configurações dinâmicas de funcionamento. Se a interface já estiver ativa e um comando exigir a elevação do MTU para tamanhos que requeiram buffers maiores, a mudança não acontecerá e o driver informará o erro -EBUSY. Isso ocorre porque os anéis de recepção são compartilhados e, nesta implementação, não têm suporte a realocação dinâmica com tráfego passante. Para efetivar aumentos expressivos de MTU, a interface precisará ser desligada, configurada e reinicializada.
Como o OpenWrt se relaciona com essa novidade?
A base dessa tecnologia não é uma invenção integral do mês de novembro. Os três patches são derivados diretos de esforços que circulam no ecossistema fora do kernel principal (downstream), originários das árvores de desenvolvimento da própria MediaTek e presentes em implementações customizadas para o projeto OpenWrt. Engenheiros como Mason Chang e Frank Wunderlich foram os responsáveis por delinear grande parte desse código original.
A missão da sexta revisão submetida em novembro foi essencialmente ajustar a série para a versão mais recente da árvore net-next, contornando conflitos surgidos após alterações prévias na função mtk_rx_alloc(). O processo de avaliação atual busca transferir e unificar essa manutenção no kernel principal. Se integrado oficialmente upstream, equipamentos compatíveis futuramente suportarão a funcionalidade direto do código-fonte do Linux, dispensando que cada fabricante mantenha pesados patches locais.
Entenda sem termos técnicos: quadros maiores deixam a internet mais rápida?
Os Jumbo Frames não conseguem aumentar a velocidade comercial contratada com seu provedor de internet.
A transmissão de informações pelas redes é feita fragmentando arquivos grandes em milhares de pacotes. Cada pacote exige cálculos matemáticos e processamento de rotas. Quadros maiores funcionam como frotas de caminhões mais longos: transportar a mesma carga passa a exigir um número menor de viagens, desafogando o trabalho de processamento de quem envia e de quem recebe.
Esse recurso opera exclusivamente em conexões de curtíssima distância controladas por você, como a comunicação interna entre um roteador poderoso e um servidor de arquivos localizado no mesmo prédio. Se os pacotes grandes tentarem alcançar a internet, serão barrados pelos equipamentos intermediários dos provedores, que operam com pacotes comuns.