É possível processar milhões de datagramas por segundo com o Windows, usando uma API independente do fornecedor? [fechadas]

Question

Estou investigando se posso implementar um aplicativo HPC no Windows que receba pequenos datagramas multicast UDP (principalmente 100-400 Bytes) em uma taxa alta, usando uma dúzia ou até 200 grupos multicast (isto é, usando MSI-X e RSS eu posso escalonar para múltiplos núcleos), faz algum processamento por pacote, e então o envia para fora. Enviando via TCP eu consegui subir o quanto eu precisava (6.4Gb / s) sem bater em uma parede, mas receber datagramas em altas taxas de pps acabou sendo um problema.

Em um teste recente em uma máquina NUMA de alta especificação com uma placa ethernet de 10 Gb de 2 portas no Windows 2012 R2 Só consegui receber centenas de milhares de datagramas UDP por segundo (remoção antecipada, ou seja, sem processar os dados, para remover a sobrecarga de processamento do meu aplicativo da equação para ver o quão rápido fica ) usando 2x12 núcleos, e a parte do kernel dos 12 grupos multicast testados parecia ser distribuída entre 8 ou 10 núcleos de um nó NUMA ( Max RSS filas foi definido como 16) - embora com um .net aplicativo, para que os aplicativos nativos possam ser mais rápidos.

Mas até mesmo Len Holgate só conseguiu receber pacotes UDP a 500kpps em seus testes do Windows RIO de alto desempenho , usando uma carga útil UDP de 1024 bytes.

No whitepaper da QLogic (OS sob teste não mencionado) os limites para O "roteamento de pacotes super pequeno" multi-threaded (de modo que inclui tanto o envio quanto o envio subseqüente?) são definidos em 5.7Mpps . Em artigos em Redes de Linux , os limites são definidos em 1Mpps a 2Mpps por núcleo (com aumento de escala supostamente mais ou menos linear) ou até mesmo 15Mpps com soluções especiais que ignorar o kernel.

Por exemplo netmap

can generate traffic at line rate (14.88Mpps) on a 10GigE link with just a single core running at 900Mhz. This equals to about 60-65 clock cycles per packet, and scales well with cores and clock frequency (with 4 cores, line rate is achieved at less than 450 MHz). Similar rates are reached on the receive side.

Então, até onde posso levar o Windows 2012 R2, com boas NICs Ethernet padrão, fazendo Ethernet padrão (em vez de, por exemplo, <> Ethernet convergente ), usando APIs independentes de fornecedor?

    

Answer 1

É possível contornar o kernel e usar o netdirect com o hpc instalado. consulte link Não consigo localizar nenhum dado de desempenho (suspeito que seria variar por fornecedor, uma vez que ele usa o hardware da NIC mais diretamente do que as outras APIs), mas deve estar no mesmo nível de outras soluções de bypass do kernel no Linux (bypass do kernel é bypass do kernel) EDITAR: Portanto, se você for se recusar a usar o hardware fornecido, não espere o desempenho que você pode obter de uma NIC padrão usando os drivers necessários. Não é necessária nenhuma Ethernet convergente (não sei ao certo como isso surgiu), mas é assim que os fornecedores expõem os recursos de hardware aos drivers do sistema operacional. Não sei por que você se refere ao papel qlogic (que se refere especificamente a usando seu hardware, algo que você está dizendo que não quer fazer), mesmo com o papel netmap (usa drivers modificados).