[GTER] pc router

[Luiz Otavio O Souza]

2012/4/26 Lista <lista.gter at gmail.com>:
> Em 26 de abril de 2012 03:16, Klaus Schneider <klausps at gmail.com> escreveu:
>
>> 2012/4/26 Lista <lista.gter at gmail.com>
>>
>> > Boa Noite pessoal, metendo o bedelho na conversa dos grande guru.
>> > Isso tudo não tem como fazer com que o kernel do linux ou melhor o
>> > soft-router possa processar as coisas diretamente via hardware,  já que
>> em
>> > si é o que mais pega em se tratando de alto trafego?
>> > Agora pelo que garimpei, não vi nada que pudesse dar um tunning no linux
>> > para que o mesmo possa consumir menos CPU(forward e pps), ao se processar
>> > uma quantidade X de pacotes, o interessante seria fazer com que o
>> hardware
>> > processe e não o linux, acho que o segredo das caixas é justamente essa,
>> > eles passa para o hardware, seja uma cpu embutida no C.I da placa de rede
>> > ou alguns processadores a parte(não conheço as caixas a fundo) deixando
>> > para o processador central uma fatia bem pequena para tal processamento.
>> >
>> O problema são os IRQs.
>> Está em desenvolvimento e acredito que na RELENG_10 do FreeBSD já esteja
>> disponível o netio, desenvolvido pelo Luigi Rizzo, mas por enquanto somente
>> para testes:
>> http://info.iet.unipi.it/~luigi/netmap/
>>
>>
>  A questão é que é voltado somente para drivers da ixgbe para intel
> 10Gbp/s, que pelo que sei, em si ela já é melhorada no driver (posts
> antigos da lista).
> Você chegou a fazer teste com esse patch?
>

O problema não são só as IRQs... (mas sim as inúmeras camadas de
software que o S.O. implementa entre um programa e o 'fio').

O netmap é, de certa forma, baseado na idéia do mmap(2)
(http://man.freebsd.org/mmap), onde o netmap mapeia os buffers de
transmissão e recepção da placa diretamente para o userland.

Com isso os programas que rodam no userland podem produzir os pacotes
e transmiti-los de forma extremamente rápida e com muito pouco
overhead. Em suma, todas as layers do S.O. são 'bypassadas' e uma vez
enviado o pacote, ele é transmitido diretamente pelo hardware (pela
placa de rede).

No site do netmap ele fala que leva aproximadamente 60~65 ciclos de
clock para mover um pacote de um programa no userland para o fio. Isso
permite que ele sature uma interface de 10Gb com 14.8 Mpps utilizando
apenas um core rodando a 900Mhz.

O outro lado do netmap é que ele 'reinventou a roda' uma vez que ele
não usa nenhuma das APIs (padronizadas) do *nix. Os programas precisam
ser modificados e convertidos para trabalhar com o netmap (os
programas passam a receber e transmitir apenas pacotes) e há muito
pouco feito nesse sentido.

Para encaminhamento de pacotes o netmap pode ser muito útil (já que
você não precisa inspecionar completamente o pacote, só um pequeno
número de informações), mas para 'servidores' com protolocos baseados
em TCP não sei se haverá muitas mudanças, pois pelo que eu entendi
você precisa receber o pacote, identificar o protocolo e reinserir o
mesmo no network stack para que ele faça o seu trabalho (se não quiser
reimplementar o TCP/IP na unha.... ouch!!!).

Acredito que ninguem fez testes significativos com o netmap justamente
pela falta do que testar.

O netmap suporta atualmente os drivers ixgbe (Intel 10G), e1000 (em e
igb - Intel 1G) e re (Realtreko 1G).

Att.,
Luiz