DPDK: Planear corretamente o processamento de pacotes no espaço do utilizador

Princípio fundamental do DPDK e classificação correta

DPDK é um framework para aplicações que precisam de processar pacotes de rede com o mínimo de sobrecarga possível no espaço do utilizador. Em vez de utilizar o caminho habitual através da pilha de rede do kernel, dos sockets e das respetivas estruturas de pacotes, uma aplicação pode utilizar diretamente placas de rede selecionadas para o seu próprio caminho de dados. Isto visa, acima de tudo, elevadas taxas de pacotes, baixas latências e um processamento facilmente planeável no caso de muitos pacotes pequenos.

A expressão „sem limites do kernel“ é, neste contexto, uma forma abreviada. O kernel do Linux continua a estar presente para o sistema operativo, a gestão da memória, os processos, a segurança e inúmeras tarefas administrativas. O DPDK também não substitui os limites da placa de rede, nem os limites do PCIe, da largura de banda de memória ou da CPU. No caso das interfaces ligadas, contorna sobretudo o percurso de dados habitual do kernel e transfere o processamento de pacotes para uma aplicação especializada.

No percurso de rede normal do Linux, os controladores de rede, o NAPI, a gestão de pacotes e a camada de sockets funcionam em conjunto. Este percurso não é, de forma geral, puramente baseado em interrupções. Um DPDK-Modo de sondagem do condutor consulta as filas de receção diretamente a partir do espaço do utilizador. A aplicação recebe pacotes em grupos, verifica-os ou altera-os e, em seguida, encaminha-os para uma fila de envio ou para uma etapa de processamento posterior.

Não se trata de um ajuste geral do kernel e, para uma aplicação Web comum com poucas ligações TCP, não é, na maioria das vezes, a primeira medida a tomar. Só quando o próprio percurso dos pacotes de dados estiver comprovadamente limitado — por exemplo, no caso de distribuição de carga L4, filtragem ou pontos finais de túnel — é que o ganho potencial justifica o esforço operacional adicional. As características dependentes da versão devem ser verificadas em relação à documentação da versão específica utilizada; uma versão candidata (Release Candidate) não é, neste contexto, equiparada a uma versão utilizada em produção.

Como funciona o caminho dos pacotes no espaço do utilizador

Na entrada, a aplicação configura uma ou mais filas Rx da placa de rede. Um núcleo de execução atribuído consulta uma fila num ciclo e recebe uma sequência de pacotes disponíveis. Estes Processamento em rajada reduz o número de chamadas de funções e o esforço administrativo por pacote. Após a classificação, o reencaminhamento ou a alteração, a aplicação coloca os pacotes, em conjunto, numa fila de transmissão (Tx-Queue).

O polling evita muitas alternâncias de interrupção no caminho de dados com elevada carga e torna o trabalho de um núcleo mais previsível. O preço a pagar é uma CPU constantemente ativa: mesmo com a fila vazia, o lcore continua a verificar se há novos pacotes. Por isso, este modelo adapta-se melhor a cargas constantemente elevadas do que a interfaces com tráfego esporádico ou muito variável.

Os dados do pacote e os metadados encontram-se em rte_mbuf-objetos. Estes provêm de um mempool criado previamente e contêm, por exemplo, o comprimento do pacote, a porta de entrada, informações de offload e, se for o caso, um hash RSS. Os pools reservados antecipadamente, uma atribuição fixa entre a fila e o núcleo e percursos de processamento curtos promovem Localização da cache e evitam estruturas de dados comuns desnecessárias.

No entanto, o Zero Copy não é uma característica automática do DPDK. O facto de os dados serem ou não copiados, e em que ponto isso ocorre, depende da placa de rede (NIC), do controlador, das descargas e da lógica da aplicação. Os frames grandes ou segmentados podem ser constituídos por vários mbufs interligados; isto é relevante, por exemplo, no caso dos frames jumbo. Quem reformular, aglutinar ou transferir dados de pacotes entre buffers incompatíveis deve ter em conta possíveis movimentações de memória no seu próprio caminho de dados.

Arquitetura, recursos e limites rígidos

A Camada de Abstração do Ambiente, ou EAL, inicializa o DPDK e disponibiliza, entre outras coisas, a reserva de memória, o acesso a dispositivos, temporizadores e a atribuição de núcleos lógicos. Com base nisso, a aplicação configura filas Ethernet, mempools e o seu processamento. Um «lcore» é, neste contexto, um núcleo lógico planeado para o DPDK, não apenas um thread de aplicação que se desloca aleatoriamente. Estas características fundamentais do EAL estão aqui comprovadas pela documentação do DPDK 25.07; os detalhes específicos da versão devem ser verificados adicionalmente para o «release tag» utilizado.

Para garantir um percurso de dados direto, é frequente que um núcleo processe um pacote na íntegra: desde a receção, passando pela decisão, até ao envio. Este modelo «run-to-completion» evita transferências entre núcleos. Por outro lado, um pipeline separa, por exemplo, o analisador, a pesquisa de fluxo e o reencaminhamento em etapas. Pode organizar as responsabilidades, mas acrescenta anéis, sincronização e, potencialmente, uma pior localização de memória entre as etapas.

O planeamento deve também ter em conta a NUMA. A fila, o lcore e os conjuntos de pacotes devem, sempre que possível, estar localizados no mesmo nó NUMA, para que o caminho dos dados não aceda regularmente à memória de outro soquete de CPU. Além disso, o desempenho alcançável depende das funcionalidades da NIC, da ligação PCIe, da largura de banda da memória, da frequência da CPU, do tamanho dos pacotes e da complexidade de cada decisão relativa aos pacotes.

Um balanceador de carga L4 pode, com as informações de IP e porta do DPDK, avaliar rapidamente, atribuir fluxos e reencaminhar pacotes. No entanto, a terminação TLS, os estados NAT complexos, o registo, as verificações de integridade ou os back-ends lentos não ficam automaticamente mais rápidos por causa disso. Da mesma forma, o plano de controlo necessita de tempo de CPU disponível para configuração, telemetria e tratamento de erros. Consequentemente, o DPDK acelera um percurso de dados claramente delimitado, mas não necessariamente todo o serviço.

Também o tamanho e a duração dos buffers de pacotes fazem parte da arquitetura. Os mempools limitam o número de buffers disponíveis em simultâneo, enquanto a aplicação tem de gerir corretamente as mudanças de propriedade. Os pools com dimensões demasiado reduzidas podem esgotar-se sob carga; as reservas excessivas ocupam memória. O tamanho adequado resulta das filas de espera, dos tamanhos de picos de tráfego, do percurso dos pacotes e dos picos de carga esperados, e não de uma regra universal.

Verificar os pré-requisitos antes da utilização do DPDK

O DPDK só se torna planificável quando o hardware, a memória e a atribuição da CPU estão em sintonia. Uma instalação, por si só, não cria um caminho de dados eficiente: o PMD tem de ser compatível com o modelo específico da NIC e os recursos têm de poder ser reservados para a aplicação. A verificação seguinte distingue os requisitos técnicos mínimos das suposições que só se aplicam ao dispositivo efetivamente utilizado.

As Hugepages são a abordagem habitual para conjuntos de pacotes de grande dimensão, mas não constituem uma condição obrigatória para todas as aplicações DPDK. O EAL também suporta a opção –no-huge. Este modo especial não constitui uma recomendação padrão equivalente: a adequação, a gestão da memória e os limites dos controladores devem ser verificados antes da fase piloto. Os princípios básicos do sistema e do EAL aqui utilizados estão documentados na versão DPDK 25.07; verifique também se as opções correspondem à versão efetivamente instalada.

Particularmente crítica é a Vinculação de dispositivos. Muitos PMDs exigem que a NIC em questão seja desligada do controlador normal do kernel e, por exemplo, ligada a vfio-pci é associada. A interface deixa então de estar regularmente disponível para a pilha de rede normal do Linux. No entanto, o procedimento concreto deve ser adequado ao PMD e não pode ser aplicado de forma generalizada a todas as placas de rede suportadas.

Os PMDs bifurcados constituem uma exceção importante. A documentação do controlador indica que esses PMDs não devem ser desligados do controlador do kernel correspondente. Nesse caso, o controlador do kernel pode permanecer ligado enquanto um caminho de dados do espaço do utilizador utiliza determinados recursos. A documentação sem versão, cujo link se encontra acima, reflete o estado de desenvolvimento 26.11.0-rc1 e não constitui um guia específico para a versão 26.07. Verifique o suporte a dispositivos e as ferramentas do kernel disponíveis no manual do PMD concretamente utilizado.

Antes de qualquer alteração, a consulta de estado seguinte fornece um inventário dos dispositivos PCI e da sua associação atual aos controladores. Ela própria não altera nenhuma associação. Execute-a no sistema de destino utilizando o caminho correspondente à estrutura de código-fonte ou de ferramentas do DPDK instalada.

./usertools/dpdk-devbind.py --status

O acesso à gestão do Plane e o caminho dos dados produtivos devem ser separados, mesmo que o PMD selecionado não substitua o controlador do kernel. A acessibilidade via SSH ou consola não deve depender de uma interface cuja ligação ou distribuição de tráfego seja alterada durante a operação piloto. Uma interface de gestão separada, um acesso fora de banda ou um caminho de recuperação local previamente testado limitam o risco de uma configuração incorreta.

Comparar DPDK, AF_XDP e Kernelstack

A escolha do caminho de dados não é uma classificação, mas sim uma decisão operacional. A pilha do kernel do Linux, o AF_XDP e o DPDK alteram, cada um à sua maneira, o esforço, o acesso aos dispositivos e o consumo da CPU. A opção adequada depende de saber se é efetivamente a taxa de pacotes ou a latência no caminho de rede que constitui o limite — ou se são a aplicação, a encriptação e os back-ends que constituem o gargalo.

O AF_XDP é uma opção intermédia para equipas que pretendem processar pacotes antecipadamente, mantendo-se, no entanto, próximas do modelo de rede do Linux. O kernel descreve um modo de cópia, bem como o Zero Copy, que requer suporte do controlador. Se o Zero Copy for explicitamente solicitado, a criação do socket pode falhar caso o controlador não ofereça essa capacidade. Para compreender melhor a camada XDP, consulte o artigo XDP e eXpress Data Path.

O DPDK, por outro lado, utiliza «Poll Mode Drivers» e processa as filas diretamente a partir da aplicação. Isto permite contornar as partes relacionadas com sockets e interrupções no percurso de dados do DPDK, mas exige a gestão da memória, das filas e da alocação de núcleos. Zero Copy Isto não constitui nem uma promessa geral de desempenho nem uma característica automática de qualquer caminho DPDK; as cópias dependem da aplicação, das transferências de carga e das transferências de memória.

Escolha a pilha do kernel se o encaminhamento, a firewall, a observabilidade e a facilidade de operação forem mais importantes do que um percurso de pacotes especializado. Considere o AF_XDP em casos de aceleração direcionada com ligação ao kernel. O DPDK só se justifica quando existe uma necessidade comprovada de elevada taxa de pacotes ou latência constante, suporte existente para a placa de rede (NIC) e uma equipa capaz de assumir de forma permanente a responsabilidade operacional adicional.

Planear de forma adequada as filas, o «CPU-Pinning» e o NUMA

Uma resistente Atribuição de filas Começa pela proximidade entre a NIC, a CPU e a memória. O EAL suporta a seleção de núcleos lógicos, a reserva de memória e a alocação de dispositivos. Para um percurso de dados simples, faz geralmente sentido atribuir de forma fixa uma fila Rx a um lcore, criar o mempool correspondente no nó NUMA local e, em seguida, transferir o processamento para uma fila Tx adequada. Estas especificações básicas do EAL estão documentadas na documentação do DPDK 25.07 e devem ser verificadas em relação à data de lançamento utilizada, no caso de opções dependentes da versão.

Um exemplo não específico de um produto para um anfitrião com dois nós NUMA seria o seguinte: a placa de rede (NIC) no nó 0 recebe duas filas de receção (Rx); cada lcore no nó 0 processa uma fila na íntegra. Os buffers de pacotes também se encontram no nó 0. Um outro núcleo, que não realiza sondagens, fica disponível para tarefas administrativas, enquanto o nó 1 é destinado a outros serviços ou a percursos de dados claramente separados.

• Percurso de dados: um lcore atribuído de forma fixa a cada fila, pools de memória locais e pares Rx/Tx claramente identificados.
• Gestão: reservar capacidade da CPU para telemetria, lógica de controlo, eventos e serviços do sistema operativo.
• Reserva: prever capacidade para picos de carga, resolução de problemas e expansões planeadas, em vez de alocar todos os núcleos de forma permanente.

Não partilhe uma fila Rx entre vários lcores. O guia PMD desaconselha a divisão de filas Rx e Tx, uma vez que os bloqueios globais necessários para tal podem comprometer significativamente o desempenho. O acesso simultâneo de vários lcores a uma fila Tx só está previsto como exceção documentada se o controlador tiver a capacidade de RTE_ETH_TX_OFFLOAD_MT_LOCKFREE indica. Verifique esta capacidade para a combinação específica de NIC/PMD; não a deduza nem a partir da velocidade da porta nem de um interruptor geral de descarregamento.

Um pipeline com etapas separadas de análise, classificação e envio pode tornar as responsabilidades mais claras. A abordagem de pipeline documentada transfere pacotes para outros núcleos através de anéis; isto resulta em acessos adicionais à memória e transferências. Para filtros simples ou encaminhamento L4, o «run-to-completion» por fila é frequentemente mais fácil de planear. Só se devem utilizar várias etapas se a divisão de tarefas justificar o esforço adicional no perfil de carga específico.

Também Transferências para o hardware não devem ser tidas em conta no planeamento. As funções de soma de verificação, segmentação, RSS ou fluxo disponíveis dependem das capacidades do dispositivo Ethernet específico e do seu PMD. Verifica-as antes da conceção e trata a ausência de descarregamento como um caso normal de planeamento, e não como uma exceção.

Monitorizar com segurança o DPDK durante o funcionamento

O funcionamento de um caminho de dados DPDK requer métricas que analisem em conjunto o processamento de pacotes e os recursos. Registe, no mínimo, os pacotes processados, rejeitados e com erros, bem como valores específicos da aplicação relativos às taxas de processamento, reservas do mempool e Distribuição da latência em vez de apenas um valor médio. Os contadores adicionais de portas, filas ou controladores disponíveis dependem do PMD específico, da NIC e da aplicação, devendo ser verificados para a combinação utilizada.

O polling constitui um conflito de objetivos deliberado. Um lcore consulta continuamente a sua fila Rx para que os pacotes possam ser processados sem recorrer ao caminho normal de interrupção. Mesmo com pouco ou nenhum tráfego, o ciclo de polling permanece, no entanto, ativo. Por isso, além dos lcores do caminho de dados, reserve capacidade de CPU para a lógica de controlo, a telemetria e o sistema operativo. A documentação EAL utilizada como complemento refere-se ao DPDK 25.07; as funcionalidades dependentes da versão devem ser verificadas na versão instalada.

Para a análise das causas, é importante a correlação temporal. Se a perda de pacotes ocorrer em simultâneo com contadores de erros, reservas do mempool em declínio ou um caminho de dados lcore sobrecarregado, estas são, numa primeira fase, pistas que podem ser verificadas, mas ainda não constituem uma prova inequívoca da causa. Os tempos de resposta variáveis podem estar relacionados, entre outros fatores, com memória distante do NUMA, tarefas concorrentes ou transferências de pipeline. Compare essas hipóteses, respetivamente, com a atribuição de núcleos, a distribuição de filas e os valores medidos no mesmo intervalo de tempo.

A captura rápida na interface não é sinónimo de registo completo e sem perdas de pacotes a longo prazo. Para estatísticas de fluxo ou análise de cabeçalhos, podem ser suficientes poucos metadados. Se for necessário guardar todos os pacotes, a largura de banda de armazenamento, o volume do buffer, a taxa de transferência de escrita e o suporte de armazenamento escolhido limitam adicionalmente a configuração. A proteção de dados e as regras de conservação são requisitos independentes que a taxa de transferência da rede não resolve.

Planeia as máquinas virtuais e os contentores como uma tarefa de integração específica. Verifica, para a plataforma em questão, como são disponibilizados o acesso aos dispositivos, a memória, a atribuição da CPU e os direitos necessários. Verifique esta combinação com o PMD utilizado, em vez de adotar parâmetros de exemplo de forma genérica. O guia do Linux cujo link se encontra aqui está atualmente na versão de desenvolvimento 26.11.0-rc1; para uma instalação em produção, é determinante a documentação da versão efetivamente instalada.

Verificar sistematicamente os erros típicos

A deteção de erros deve, em primeiro lugar, distinguir os sintomas observáveis das possíveis causas. Não altere simultaneamente a ligação do controlador, o número da fila e os parâmetros de memória, pois, nesse caso, já não será possível identificar o fator desencadeante. Contadores não destrutivos, informações sobre a configuração e uma comparação entre a fila afetada e a não afetada fornecem, na maioria das vezes, as pistas mais fiáveis antes de se proceder a qualquer intervenção.

Se o comportamento da fila for anómalo, verifica o proprietário da fila e o nó NUMA do mempool. No modelo «run-to-completion», o lcore atribuído processa a receção, o processamento e o envio; um pipeline transfere os pacotes para outros núcleos. No entanto, não dividas a fila de receção (Rx) entre lcores. O acesso simultâneo a uma fila de transmissão (Tx) só é permitido se tiver sido notificado RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-Esta funcionalidade está prevista como uma exceção. Um bloqueio autoaplicável faz com que a partilha de filas não seja a estratégia de escalabilidade recomendada.

Na ausência de offloads de hardware, a questão correta não é apenas saber qual a opção que foi ativada, mas sim quais as capacidades que o dispositivo e o PMD disponibilizam efetivamente. Uma aplicação pode planear uma função pretendida, mesmo que esta não esteja disponível para esse modelo. Compara o suporte para a NIC específica com as capacidades comunicadas em tempo de execução, antes de condicionar o percurso de dados a essa descarga.

Os resultados do testpmd devem ser considerados como uma linha de base ou um teste funcional, e não como uma prova de desempenho da aplicação posterior. No modo de encaminhamento de E/S, os pacotes são encaminhados sem alterações, sem que o seu conteúdo seja analisado para processamento técnico. Este modo não reproduz analisadores, tabelas de fluxo, NAT, encriptação nem o estado do protocolo. A documentação sem versão, cujo link se encontra aqui, refere-se à versão 26.11.0-rc1; verifique o comportamento no manual da versão instalada. Registe o modo de encaminhamento, o tamanho dos pacotes, o número de filas Rx/Tx e os núcleos de encaminhamento e repita a comparação com a lógica de processamento real.

Implementação, manutenção de versões e decisão de implementação

Começa por um teste isolado e um perfil de carga: tamanhos dos pacotes, carga de pico, número de fluxos e etapas de processamento necessárias. Verifica a NIC específica, incluindo o controlador de modo de sondagem adequado e as funções necessárias, com base na visão geral oficial do hardware e na matriz de controladores. O facto de um fabricante constar da lista não confirma, por si só, nem todas as placas nem todas as descargas. Em seguida, testa com lógica de aplicação real, e não exclusivamente com um exemplo de reencaminhamento.

Regista a versão do DPDK, o firmware, os controladores, o kernel e a configuração para cada teste. Antes de efetuar uma atualização, leia as notas de lançamento da versão específica prevista e documente quais as alterações relevantes para o seu próprio percurso de dados. As notas de lançamento de versões diferentes não substituem esta correspondência, uma vez que as funcionalidades e restrições podem variar entre versões.

Um ponto específico a ter em conta nas Notas de Lançamento do DPDK 26.07 é a alteração do algoritmo de limpeza/reabastecimento da cache do mempool: o seu tamanho efetivo corresponde agora ao tamanho configurado; anteriormente, era 50 por cento maior. Apenas quando cada lcore de um mempool retira exclusivamente objetos ou devolve exclusivamente objetos é que as Notas de Lançamento recomendam duplicar o tamanho configurado da cache, para evitar uma possível duplicação da taxa de falhas de cache. Isto aplica-se, por exemplo, a pipelines com lcores Rx e Tx separados, e não de forma generalizada ao modo «run-to-completion». A alteração diz respeito à versão 26.07; a página histórica da versão referida encontra-se agora na documentação relativa à versão 26.11.0-rc1.

Comece com um projeto-piloto de âmbito limitado e critérios de interrupção bem definidos. Compare o débito, os percentis de latência elevada, as perdas de pacotes e os requisitos de CPU em condições idênticas às da operação atual. Verifique a monitorização, os reinícios e o regresso à configuração anterior. Tenha em conta os custos operacionais; não é possível deduzir daí uma garantia geral de débito.

A adoção do DPDK justifica-se, sobretudo, quando os benefícios medidos justificam o esforço adicional de manutenção. Para contextualizar a plataforma de sistema circundante, o artigo acrescenta Kernel do Linux em serviços de alojamento O planeamento. No caso dos serviços de alojamento habituais, mantém também o caminho de rede existente como base de comparação no teste.