[GTER] Linux + ksoftirqd

[Rafael Koike]

É Luiz,

Legal você comentar como realmente é pois eu apenas criei uma ideia de como
poderia ser :-)
Parece que ainda não perdi meus skills de programador :-D
Bem, diria que um mix de moderação de interrupção (que é parecido com
polling) com ring (Que eu penso que também poderia ser por tamanho de
buffer ao invés de apenas numero de pacotes) seria uma boa também.

Obrigado pelas explanações.

Mas se temos ambos os modelos porque ainda temos casos de usuários
experimentando alta utilização de ksoftirq com baixo throughput?
Drivers incorretos?
Configuração dos drivers incorretos? (moderação de irq e ring desligados?)




Em 30 de julho de 2015 11:34, Luiz Otavio O Souza <lists.br at gmail.com>
escreveu:

> 2015-07-30 0:07 GMT-03:00 Rafael Koike:
> [...]
> >
> > Já existem placas de rede onde o chip controlador da Intel ou da Broadcom
> > implementam buffers onde a placa espera alguns pacotes chegaram por um
> > determinado tempo até que se gere uma interrupção e isso reduz bastante o
> > numero de softirqs e uma redução do processamento.
>
> Exato isso isso se chama moderação de interrupção, as NICs ajustam o
> número de interrupções geradas para a CPU conforme aumenta o número de
> pacotes recebidos de forma que a CPU não seja interrompida com muita
> frequência e posso processar os pacotes em lote (ao invés de fazer
> isso pacote a pacote:
>
> http://www.intel.com/content/www/us/en/embedded/products/networking/gbe-controllers-interrupt-moderation-appl-note.html
>
> Isso aposentou o polling no FreeBSD, que não é recomendado para as
> NICs mais modernas - 10/40/100Gb (há casos específicos onde o polling
> ainda ajuda, mas ele não deve mais ser usado indiscriminadamente).
>
> [...]
>
> > Vamos imaginar que o buffer tem 256K
> > Então ao receber pacotes de 64bytes (84 com o header ethernet) e
> > armazena-los em buffer até chamar a irq voce geraria uma irq a cada 3023
> > pacotes e em uma interface de 1Gbps voce teria apenas 489 irq por segundo
> > para atingir 1Gbps.
> > Porem ao custo de bufferizar 3023 pacotes e só depois disso entregá-los
> > (Aumento de latência pois os pacotes ficam no buffer até encher)
> > Neste caso o driver precisa determinar um tempo máximo de espera no
> buffer
> > para chamar uma irq de forma a não aumentar muito a latência e ao mesmo
> > tempo reduzir o numero de interrupções.
>
> O buffer não funciona assim, o driver configura os ring descriptors
> para tx e rx (buffers em anel para receber transmitir pacotes) com
> tamanho fixo em número de pacotes e não pelo tamanho do buffer (um
> ring de 1024 descriptors pode receber até 1024 pacotes, sejam eles
> jumbo packets, sejam eles pacotes de 64bytes). Então quando você
> recebe um certo número de pacotes a NIC gera uma interrupção. Por isso
> o tamanho dos pacotes ainda influencia muito.
>
> >
> > Mas existem outras técnicas de reduzir latência e reduzir interrupções
> > também como DMA (Direct Memory Access) onde o driver consegue mandar o
> > pacote quando chega na placa de rede direto para a memória RAM e o
> processo
> > pega o pacote sem precisar que o driver gere uma irq.
> > Mas para funcionar bem o DMA o software precisa acessar o driver de rede
> e
> > informar os processos onde está o pacote na memória e depois precisa
> > decidir qual thread ou processo é o destinatário do pacote.
>
> Todas interfaces de rede que conheço usam DMA (apenas com raras (e
> estranhas) exceções).
>
> Mesmo com DMA a placa ainda utiliza interrupções, essa é a única forma
> do hardware avisar a CPU que existe trabalho para ser feito.
>
> A vantagem do DMA é que o driver não precisa copiar byte a byte (ou
> palavra a palavra) o dados recebidos da placa de rede. O driver
> configura os rings de tx e rx e aponta lá uma area da memoria aonde a
> interface de rede pode colocar os pacotes e quando você recebe a
> interrupção os dados do pacote já estão nessa area da memória, sem
> nenhum trabalho adicional.
>
> HTH,
> Luiz
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>