Como os pacotes são agendados das filas da interface de rede para as CPUs e, em seguida, para os threads para processamento? O que precisa ser considerado quando se trata de como os pacotes são divididos em filas, interrupções de hardware versus softirqs, localidade de CPU / memória / aplicativo / thread e multithreading versus daemons multiprocessos, para evitar o maior número possível de replicação / cópia de pacotes? / p>
Eu tenho um daemon de rede multithread (digamos, o resolvedor Unbound) rodando com 16 threads nativas no Debian amd64 com o Linux 2.6.32 (sim, antigo), então a carga do aplicativo é espalhada por 16 CPUs. A placa de rede é uma bnx2 (BCM5709S) com suporte para 8 filas MSI-X rx / tx. O IRQ de cada fila é atribuído a uma CPU separada, mapeando estatisticamente a afinidade de interrupção em / proc / irq / n / smp_affinity (o irqbalance nunca fez um bom trabalho) e o tipo de hash de fila (tipo RSS) é o padrão (IP src + dst , TCP sport + dport), com a chave de hashing padrão.
Tudo isso ajuda a distribuir a carga, mas não uniformemente: normalmente há um encadeamento de aplicativo que faz o dobro do trabalho (= solicitações por segundo) de outros encadeamentos e uma taxa de softirq de CPU (provavelmente a que manipula esse encadeamento específico) é duas vezes de outras CPUs.
As CPUs têm hyper-threading ativado, mas eu ainda não fiz nada para espalhar a carga através de núcleos 'reais' (o que eu realmente deveria).
O Linux vem com um documento de redimensionamento de rede bastante abrangente, mas estou com saudades alguns espaços em branco:
O documento diz isso sobre a configuração de RSS:
A typical RSS configuration would be to have one receive queue for each CPU if the device supports enough queues, or otherwise at least one for each memory domain, where a memory domain is a set of CPUs that share a particular memory level (L1, L2, NUMA node, etc.).
P: Como determino a configuração do domínio da CPU / cache / memória para o meu servidor?
As informações sobre o RFS (Receive Flow Steering) parecem responder a algumas das minhas perguntas sobre como colocar o pacote no processador / encadeamento correto:
The goal of RFS is to increase datacache hitrate by steering kernel processing of packets to the CPU where the application thread consuming the packet is running.
P: No caso de resolução de DNS, normalmente há um pacote de consulta e um pacote de resposta. Com um daemon multithread, somente um único thread executaria bind () + recvfrom () e, portanto, teria que manipular todos os novos pacotes de entrada, antes de agendar o trabalho em outros threads? Este caso de uso específico se beneficiaria da operação bifurcada (um processo por CPU)?
P: Receberia instruções de fluxo e, em seguida, aplica-se melhor a um daemon TCP multissegmentado?
P: Como você determinaria se iria para operações multithreading ou multiprocessos? Obviamente, há a memória compartilhada e as estruturas de dados, a contenção de recursos, etc., mas estou pensando em relação ao fluxo de pacotes e aos ouvintes de aplicativos.
P: Sem receber direção de fluxo, ou com serviços UDP simples, um pacote pode chegar na CPU 'errada' e, portanto, será remarcado para a CPU 'correta'? Isso acionará um softirq NET_RX?
P: Existe um softirq NET_RX entre a fila da NIC e a CPU? Existe também um entre a CPU e o segmento / processo de escuta? Poderia haver ainda outro se o segmento de recebimento agendava o pacote para um segmento de trabalho, se é possível?
Pena que não há vídeo ou detalhes adicionais do talk do netconf 2011 de Ben Hutchings, onde ele cobre a maior parte essas coisas. Os slides são um pouco breves.
Tentarei atualizar para um kernel mais recente com uma versão de desempenho utilizável e, em seguida, inspecionar o que as CPUs estão fazendo, talvez achando que a CPU com maior carga está à altura das outras.
Nota: Não estou tentando resolver um problema específico aqui, mas estou tentando entender como essas coisas funcionam no kernel do Linux. Também estou ciente das várias opções para a coalescência de interrupções.