NAPI vs interrupções adaptativas

Alguém poderia explicar como duas tecnologias a seguir são usadas para reduzir a sobrecarga de interrupção sob alta carga de rede?

1. Adaptive-rx / Adaptive-tx e
2. NAPI;

Gostaria de receber uma resposta que explique a diferença mais próxima do nível de fonte do kernel do linux? Também gostaria de ouvir como forçar a NIC a pesquisar / interromper o modo coalescente em carga que é de ~ 400 Mbps.

Mais informações:

O problema parece ser que os drivers bnx2 e e1000 ignoram o comando "ethtool -C adaptive-rx on". Provavelmente, esses drivers não oferecem suporte a interrupções adaptativas. Embora o manual de referência do Broadcom Programmer diga que esse recurso deve ser suportado pelo hardware da BCM5709 NIC.

Então, decidi tentar a NAPI e reduzir o peso de 64 para 16 na chamada de função netif_napi_add () para forçar a NIC no modo de pesquisa sob carga muito menor, mas infelizmente isso não deu certo. Eu acho que a NAPI não precisa de nenhum suporte especial de hardware na NIC, está correto?

O hardware que estou usando é o BCM5709 NIC (ele usa o driver bnx2). E o sistema operacional é o Ubuntu 10.04. A CPU é XEON 5620.

O principal princípio por trás da moderação de interrupção é gerar menos de uma interrupção por quadro recebido (ou uma interrupção por conclusão do quadro de transmissão), reduzindo a sobrecarga do SO encontrada ao reparar interrupções. O controlador BCM5709 suporta alguns métodos em hardware para interrupções coalescentes, incluindo:

• Gere uma interrupção após receber quadros X (quadros rx no ethtool)
• Gere uma interrupção quando nenhum quadro for recebido após o X usecs (rx-usecs no ethtool)

O problema com o uso desses métodos de hardware é que você precisa selecioná-los para otimizar a taxa de transferência ou a latência; não pode ter os dois. A geração de uma interrupção para cada quadro recebido (rx-quadros = 1) minimiza a latência, mas o faz a um alto custo em termos de sobrecarga do serviço de interrupção. Definir um valor maior (digamos, rx-frames = 10) reduz o número de ciclos de CPU consumidos, gerando apenas uma interrupção para cada dez quadros recebidos, mas você também encontrará uma latência mais alta para os primeiros quadros naquele grupo de dez.

A implementação da NAPI tenta aproveitar o fato de o tráfego chegar em grupos, para que você gere uma interrupção imediatamente no primeiro quadro recebido e, em seguida, alterne imediatamente para o modo de pesquisa (ou seja, desative as interrupções), porque mais tráfego ficará logo atrás. Depois de pesquisar um número de quadros (16 ou 64 na sua pergunta) ou algum intervalo de tempo, o driver reativará as interrupções e reiniciará.

Se você possui uma carga de trabalho previsível, é possível selecionar valores fixos para qualquer um dos itens acima (NAPI, rx-frames, rx-usecs) que oferecem a troca certa, mas a maioria das cargas de trabalho varia e você acaba fazendo alguns sacrifícios. É aqui que o adaptive-rx / adaptive-tx entra em cena. A idéia é que o driver monitore constantemente a carga de trabalho (quadros recebidos por segundo, tamanho do quadro etc.) e ajuste o esquema de coalescência de interrupção de hardware para otimizar a latência em situações de baixo tráfego ou otimizar o rendimento em situações de alto tráfego. É uma teoria interessante, mas pode ser difícil de implementar na prática. Apenas alguns drivers o implementam (consulte http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce ) e os drivers bnx2 / e1000 não estão nessa lista.

Para uma boa descrição de como cada campo coalescente ethtool deve funcionar, consulte as definições da estrutura ethtool_coalesce no seguinte endereço:

http://fxr.watson.org/fxr/source/include/linux/ethtool.h?v=linux-2.6#L111

Para sua situação específica (taxa de transferência de ~ 400 Mb / s), sugiro ajustar os valores de rx-frames e rx-usecs para obter as melhores configurações para sua carga de trabalho. Observe tanto a sobrecarga do ISR quanto a sensibilidade do seu aplicativo (httpd? Etc.) à latência.

Dave