KNOD: O processamento de pacotes de rede diretamente na GPU AMD, dentro do kernel Linux, sem o ROCm. Com milhares de threads em paralelo vs. um pacote por núcleo de CPU. O futuro da networking chegou. Leia mais:
A revolução silenciosa que está acontecendo no kernel do Linux pode mudar para sempre a forma como pensamos sobre processamento de rede. No último domingo, foram publicadas no Linux kernel mailing list um conjunto de patches para um projeto chamado KNOD (in-kernel network offload device).
E o que ele faz é, para dizer o mínimo, impressionante: permite que o kernel do Linux descarregue o processamento de pacotes de rede diretamente para a GPU, sem depender de bibliotecas de espaço de usuário como ROCm ou CUDA.
Se você trabalha com infraestrutura de rede, segurança, load balancing ou qualquer área que exija processamento de pacotes em alta velocidade, este é um daqueles momentos em que vale a pena parar e prestar atenção.
O que é exatamente o KNOD e por que ele é tão revolucionário ?
Uma nova camada no kernel Linux
KNOD significa In-kernel Network Offload Device — um dispositivo de descarregamento de rede dentro do kernel.
Na prática, é um mecanismo que permite que o kernel Linux entregue o processamento de pacotes de rede para a GPU, sem precisar sair do espaço do kernel.
A grande sacada aqui é que tudo acontece dentro do kernel. Não há dependência de bibliotecas de espaço de usuário como AMD ROCm, nem de CUDA da NVIDIA.
O próprio kernel gerencia as filas da GPU, compila o programa Just-In-Time (JIT) para o código da GPU e despacha o trabalho.
O problema que o KNOD resolve
Para entender por que isso é tão importante, é preciso olhar para o cenário atual do processamento de pacotes em alta velocidade.
Hoje, quando um servidor precisa processar muitos pacotes de rede fazendo algo além do trivial — como balanceamento de carga na camada 4 (L4) ou criptografia IPsec — cada núcleo da CPU processa um pacote por vez.
Para escalar, você precisa de mais núcleos de CPU. E chega um ponto em que simplesmente não há núcleos suficientes, ou o custo de adicionar mais CPUs se torna proibitivo.
A GPU tem um "formato" completamente diferente: milhares de núcleos (ou lanes) executando o mesmo pequeno programa sobre muitos pacotes ao mesmo tempo (SIMT — Single Instruction, Multiple Threads).
É exatamente isso que o KNOD explora. A placa de rede (NIC) envia os pacotes recebidos diretamente para a memória da GPU via DMA (Direct Memory Access), a GPU executa o programa em um lote de pacotes em paralelo, e só o resultado volta: uma decisão (veredict) para cada pacote, além do próprio pacote para aqueles que precisam ser entregues ao host.
O resultado ? A CPU não paga mais o custo do processamento pacote por pacote, e a vazão (throughput) escala com a ocupação da GPU, não com a contagem de núcleos da CPU.
Como o KNOD funciona na prática?
Do kernel para a GPU — sem rodeios
O fluxo de trabalho do KNOD é elegantemente simples:
1. A placa de rede recebe os pacotes.
2. A NIC envia os pacotes via DMA diretamente para a memória da GPU.
3. O kernel, que já compilou o programa XDP (eXpress Data Path) ou as associações de segurança IPsec (SA) para código de GPU, despacha o trabalho para a GPU.
4. A GPU executa o programa sobre um lote de pacotes em paralelo.
5. A GPU retorna o resultado (verdict) para cada pacote, e os pacotes que precisam seguir para o host são encaminhados.
E tudo isso — tudo — acontece dentro do kernel. Nenhum processo em espaço de usuário precisa ser iniciado, nenhuma biblioteca precisa ser carregada, nenhuma runtime de GPU precisa estar em execução.
Transparência para programas existentes
Um dos aspectos mais interessantes do KNOD é que ele permite o descarregamento de programas XDP existentes e de associações de segurança IPsec de forma transparente. Ou seja, você não precisa reescrever seus programas do zero.
O KNOD se integra aos caminhos de offload existentes (XDP, xfrm) e não exige nada instalado ou em execução no espaço do usuário.
Isso significa que, se você já usa XDP para o balanceamento de carga ou processamento de pacotes, o KNOD pode potencialmente acelerar seu workload sem uma reformulação completa da sua arquitetura.
Por que a AMD? E quanto à NVIDIA e Intel?
A vantagem do driver open-source da AMD
O desenvolvimento do KNOD foi feito em hardware GCN (com a Radeon RX Vega) e em hardware RDNA2. E há uma razão clara para isso: a AMD tem a vantagem distinta de ter uma pilha de drivers totalmente open-source e integrada ao kernel upstream.
Isso facilita enormemente o desenvolvimento de projetos como o KNOD, que precisam de acesso direto e profundo ao hardware da GPU a partir do kernel.
E a NVIDIA ?
Do lado da NVIDIA, a situação é mais complicada. Embora exista um driver open-source oficial da NVIDIA, ele não está integrado ao kernel upstream. E os drivers Nouveau e NOVA ainda não são maduros o suficiente para assumir um trabalho tão complexo.
Isso não significa que o KNOD nunca chegará às GPUs NVIDIA — mas, por enquanto, o foco é inteiramente na AMD.
Intel pode entrar na jogada?
O suporte a GPUs Intel com KNOD pode ser uma opção no futuro. Mas, como tudo no desenvolvimento open-source, isso depende de interesse, contribuições e maturidade dos drivers. Por ora, o trabalho está 100% focado em AMD.
Quem está por trás do KNOD ?
O projeto foi apresentado inicialmente no Linux Plumbers Conference do ano passado, no Japão, por Taehee Yoo. Os patches foram publicados no último domingo sob o banner de Request For Comments (RFC) no Linux kernel mailing list.
Isso significa que o projeto ainda está em fase inicial de discussão e revisão. Mas o fato de já haver um protótipo funcional rodando em hardware GCN e RDNA2 é um sinal extremamente promissor.
O que o KNOD significa para o futuro da Infraestrutura de Rede ?
Menos CPUs, mais GPUs nos data centers
Se o KNOD for aprovado e integrado ao kernel Linux principal, podemos estar diante de uma mudança significativa na arquitetura de servidores de rede.
Em vez de gastar dezenas de núcleos de CPU em processamento de pacotes, os data centers poderão usar GPUs para esse trabalho pesado, liberando a CPU para outras tarefas.
Imagine um servidor de balanceamento de carga que, em vez de usar 16 núcleos de CPU para processar milhões de pacotes por segundo, usa uma única GPU para fazer o mesmo trabalho com folga, enquanto a CPU fica livre para gerenciar conexões, logs e outras operações.
Processamento de pacotes em linha-rate
O KNOD promete processamento de pacotes em linha-rate (line-rate) para workloads que fazem trabalho não-trivial por pacote. Isso é especialmente relevante para:
- Balanceamento de carga L4
- Criptografia IPsec
- Firewalls de alto desempenho
- DDoS mitigation
- Telemetria e monitoramento de rede
Um passo em direção à computação heterogênea no kernel
O que você precisa para começar a testar o KNOD?
Por enquanto, o desenvolvimento foi feito em:
- Arquitetura GCN: Radeon RX Vega.
- Arquitetura RDNA2.
Se você tem uma GPU AMD dessas gerações, já pode começar a pensar em testar (assim que os patches forem integrados e estabilizados).
Software necessário
- Kernel Linux com os patches do KNOD aplicados (ainda em RFC).
- Driver AMDGPU (que já faz parte do kernel upstream).
- Conhecimento em XDP (eXpress Data Path) ou IPsec para criar os programas que serão descarregados.
Produto Recomendado
Notebook Gamer ASUS TUF Gaming F16 – potência que não te deixa na mão!
Com Intel Core i5 de 14ª geração e NVIDIA GeForce RTX 5050 (arquitetura Blackwell com DLSS 4), você roda os jogos mais pesados com gráficos superiores e FPS nas alturas. A tela 16" Full HD+ IPS de 165 Hz entrega fluidez e imersão total. Bateria de 8100 mAh, resfriamento avançado com dissipador de ponta a ponta e resistência militar para durar anos.
Notebook ASUS TUF Gaming F16 -> https://link.amazon/A0iz2mZvX
Eu ganho uma comissão quando você faz uma compra .
FAQ — Perguntas frequentes sobre o KNOD
❓ O KNOD substitui o ROCm?
Não. O KNOD é um mecanismo que opera dentro do kernel e não depende do ROCm, que é uma plataforma de computação em espaço de usuário. O ROCm continua sendo relevante para aplicações de machine learning, HPC e outras que precisam da pilha completa de bibliotecas e ferramentas da AMD. O KNOD é focado em processamento de pacotes de rede de alta velocidade diretamente no kernel.
❓ Posso usar o KNOD com qualquer GPU AMD?
Por enquanto, o desenvolvimento foi feito em GPUs com arquitetura GCN (como a Radeon RX Vega) e RDNA2. GPUs mais antigas ou mais novas podem ou não funcionar, dependendo do suporte do driver AMDGPU e das adaptações necessárias no código do KNOD. A tendência é que o suporte se expanda com o tempo.
❓ Quando o KNOD estará disponível no kernel Linux principal?
Os patches foram publicados como RFC (Request For Comments) no último domingo. Isso significa que o projeto ainda está em fase de discussão e revisão pela comunidade do kernel. Não há uma data definida para integração ao kernel principal, mas o fato de já haver um protótipo funcional é um sinal muito positivo. Acompanhe as atualizações no Linux kernel mailing list e no Phoronix para saber quando isso acontecer.
Conclusão: O KNOD é o futuro do processamento de pacotes?
O KNOD representa uma mudança de paradigma no processamento de rede no Linux. Pela primeira vez, temos um mecanismo que permite descarregar o processamento de pacotes para a GPU diretamente do kernel, sem dependências externas, sem bibliotecas de espaço de usuário, sem complicações.
Para empresas que operam infraestrutura de rede em larga escala, isso pode significar economia significativa em custos de hardware (menos CPUs, mais GPUs) e ganhos enormes de desempenho (processamento paralelo em massa vs. processamento sequencial por núcleo).
O caminho ainda é longo — os patches estão em RFC, e a comunidade do kernel precisará discutir, revisar e testar. Mas o potencial é inegável.
E você, o que achou do KNOD? Vai testar assim que os patches estiverem disponíveis? Já usa XDP ou IPsec em produção? Deixe seu comentário abaixo e compartilhe este artigo com quem também se interessa pelo futuro do networking no Linux.
Nenhum comentário:
Postar um comentário