[GTER] Linux + ksoftirqd

Thu Jul 30 00:07:35 -03 2015

Quando o hardware tem um ASIC (Application Specific Integrated Circuits)
ele implementa parte ou todo o processo de comutação e até mesmo roteamento
de pacotes dentro do harware.
Com isso voce não precisa gerar uma interrupção para chamar a atenção da
CPU para processar determinado dado.
Dai a CPU fica livre para fazer outras coisas como autenticação,
monitoramento, etc.
Tudo vai depender do tipo de off-load que voce tira da CPU e joga para o
ASIC. Isso pode ser desde um simples L2 forwarding, passando por static
routing e até chegando a um dynamic routing.
O que sobra para a CPU é bem menos e o numero de softirqs será muito menor.

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.

Imagino que o kernel do linux preferiu evoluir o driver de rede junto das
controladoras Intel e Broadcom do que partir para um modelo de polling.
São estratégias diferentes que visam atingir o mesmo objetivo. Reduzir o
numero de interrupções do processador e conseguir processar mais pacotes.
Quem está tendo problemas de alta utilização com processamento de pacotes
tem que analisar qual é  o chipset da placa de rede, qual o driver, qual a
configuração do driver, qual a afinidade da CPU e que tipo de pacote está
sendo processado.

As vezes a pessoa não tem problemas porque o tráfego que está passando pelo
roteador tem pacotes de tamanho razoável.
Mas se você começa a receber muitos pacotes pequenos de 64bytes imagine que
é bem possível que você está gerando uma irq para cada pacote quando em
outros casos você gera uma irq para pacotes de 1200 a 1400 bytes
Vamos a um calculo simples.
Se voce está recebendo pacotes de 64 bytes (incluindo o header ethernet
voce terá 84 bytes) e a velocidade do seu link é de 1Gbps ou 10Gbps

Para facilitar segue uma tabela.

Se cada pacote que chegar você gerar uma irq para informar a CPU que o
pacote chegou e ela precisa processar você terá mais de 1 milhão de irq por
segundo só para processar quase 1 Gbps de tráfego.
É certo que dificilmente apenas um núcleo consiga processar 1M de irq.
Então a solução é você agrupar mais pacotes de 64bytes até chamar a irq.
E onde muda isso?
O hardware precisa implementar algum buffer para ir armazenado os pacotes
(Boas placas de rede tem buffers de entrada e buffers de saída)
E também o driver precisa reconhecer que o hardware tem o buffer e com isso
utilizar isso de forma a não interromper o kernel com irq enquanto voce não
encher o buffer até um tempo limite.
 (Senão voce teria pacotes pequenos aguardando um tempão no buffer até
novos pacotes chegarem para que o driver chame uma irq)

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.

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.

Não sei, pensando agora a solução de polling do FreeBSD parece tão simples
e fácil de implementar que toda essa complexidade de ASIC da placa de rede,
driver, DMA, etc pode não valer a pena.

Mas tudo são conjecturas de técnicas de processamento de pacotes com seus
prós e contras.

Em 28 de julho de 2015 13:11, Fernando Frediani <fhfrediani at gmail.com>
escreveu:

> Dois produtos comerciais bastante utilizados por muitas pessoas aqui na
> lista, RouterOS (Mikrotik) e ExtremeXOS (Extreme Networks) tem Linux como
> base e passam multiplos Gigabits de tráfego numa boa (desconsidere
> problemas não relacionados como as rotas presas no RouterOS). Digo 10+ Gbps
> em uma caixa de 1U.
>
> Sabido disso que tipo de técnica será que eles usam para lhe dar com o
> ksoftirqd quando é o caso, ou será que todos desenvolveram uma técnica
> proprietária só sua ?
>
> "/It says modifications were made in the Linux kernel to improve the
> packet forwarding capabilities of the software, as well as hardening its
> security and to make it run on Extreme’s custom processors and ASICs.
> Extreme says that in accordance with the GPL, it will be pushing its
> changes to Linux back to the open-source community, which should be
> interesting for Linux router enthusiasts to see./"[1]<
> http://www.networkworld.com/article/2333244/software/extreme-networks-puts-linux-to-work-in-routing-switch.html
> >
>
> Abraços
> Fernando
>
> [1] -
> http://www.networkworld.com/article/2333244/software/extreme-networks-puts-linux-to-work-in-routing-switch.html
>
> On 28/07/2015 08:12, Kalil de A. Carvalho wrote:
>
>> Bom dia a todos.
>>
>> Esta discussão começou com uma duvida historia, por assim dizer, porem sem
>> resposta. O curioso é que estou passando por este problema, ou estava não
>> estou certo, e não vi solução em nenhum forum. Os comentários que vejo são
>> bastante destoantes para um problema em comum, fora que as discussões são
>> bem antigas a mais recente data de 2012, quanto tem respostas.
>>
>> Estou rodando com o kernel 3.10.0-123 e passando por problemas de pessoas
>> rodando com bem mais antigos. O meu ambiente não é tão grande assim, cerca
>> de 3Gbps nos dois sentidos e o problema é intermitente e sem rasão clara
>> pois monitoramos todos os eventos considerados, e orientados pelo suporte,
>> que poderia causar esta situação e nada foi descoberto.
>>
>> No inicio coloquei que " estou passando por este problema, ou estava não
>> estou certo" porque realizei uma atualização, ainda não pude reiniciar o
>> equipamento para mudar o kernel, mas a maquina esta se comportando bem
>> desde então. Fez sete dias sem eventos, mas como já tinha dito é algo
>> intermitente, sem padrão e causa definida.
>>
>> Por tudo que li sobre o assunto me parece que é um problema que atinge um
>> pequeno grupo insuficiente para ser considerado algo que a equipe do
>> kernel
>> deposite tempo para resolver ou acredita que tenha sido resolvido... não
>> sei mas o fato é que o problema existe apesar de poucos relatarem.
>>
>> Como ultima solução estamos vendo a possibilidade de mudar para FreeBSD
>> com
>> OpenBGPD.
>>
>> Atenciosamente,
>>
>> 2015-07-28 1:05 GMT-03:00 Fernando Frediani <fhfrediani at gmail.com>:
>>
>>  Pois é. Estou aqui pensando que existem produtos comerciais baseados em
>>> Linux que alguma coisa fizeram para resolver esse problema.
>>> É a mesma coisa de TDMA para Wifi. Ubiquiti fez, Mikrotik também, até a
>>> Intelbras tem algo parecido, mas se você procurar para algo community
>>> como
>>> OpenWrt não tem.
>>>
>>> Fernando
>>>
>>> On 27/07/2015 21:04, Raimundo Santos wrote:
>>>
>>>  2015-07-27 16:38 GMT-03:00 Fernando Frediani <fhfrediani at gmail.com>:
>>>>
>>>>   E por que será que até hoje não fizeram pra Linux funcionar igual
>>>>
>>>>> funciona
>>>>> pra FreeBSD que aparentemente funciona bem melhor ?
>>>>>
>>>>>   Pois é, boa pergunta.
>>>>>
>>>> Mas penso que tenha a ver com minha observação final: escolha de
>>>> projeto.
>>>> Escolheram fazer assim no passado, e provavelmente essa forma resolvia o
>>>> problema da época muito bem. Mas como é algo extremamente fundamental,
>>>> outras partes do kernel cresceram sobre ele. Mudar algo tão estrutural
>>>> assim não é nada fácil.
>>>>
>>>> FreeBSD é um sistema cujo foco sempre foi esse da ótima performance de
>>>> rede
>>>> (entre outras); já o Linux cresceu demais como um sistema para
>>>> performance
>>>> em aplicações. Talvez nem haja interesse de melhorar isso pra comunidade
>>>> (em produtos fechados, quem sabe).
>>>>
>>>> []s
>>>> Raimundo Santos
>>>> --
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>
>>>>  --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>>
>>
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter