[FUG-BR] ALTQ + Intel Drivers.

Quarta Maio 22 00:06:12 BRT 2013

>
> Message: 5
> Date: Tue, 21 May 2013 19:38:26 -0300
> From: Marcelo Gondim <gondim em bsdinfo.com.br>
> Subject: Re: [FUG-BR] ALTQ + Intel Drivers.
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>         <freebsd em fug.com.br>
> Message-ID: <519BF762.5030802 em bsdinfo.com.br>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Em 21/05/13 18:14, Renato Botelho escreveu:
> > On 05/21/2013 04:52 PM, Bruno Araújo wrote:
> >> Em 21/05/2013, às 16:32, Renato Botelho <rbgarga em gmail.com> escreveu:
> >>
> >>> On 05/21/2013 04:28 PM, Marcelo Gondim wrote:
> >>>> Em 21/05/13 15:52, Renato Botelho escreveu:
> >>>>> On 05/21/2013 02:57 PM, vic wrote:
> >>>>>> Em 2013-05-21 12:01, Luiz Gustavo Costa escreveu:
> >>>>>>> EXATAMENTE garga !!! eu sou um que to doido pra ver o vimage 100%
> !!
> >>>>>>> mas
> >>>>>>> ele ainda é experimental e as panes são normais.
> >>>>>>>
> >>>>>>> isso tá bem documentado.
> >>>>>>>
> >>>>>>> eu acho que a dedicação agora esteja no bhyve (Acho que é assim que
> >>>>>>> escreve :p)
> >>>>>>>
> >>>>>> Sim, é experimental, mas eu tenho usado com sucesso o vimage.
> Contudo
> >>>>>> esqueça de usar o pf ou algum módulo externo do FreeBSD (como o
> >>>>>> virtualbox por exemplo).
> >>>>>>
> >>>>>> Meu ambiente está rodando FreeBSD 9.1 + vimage + RCTL (esse último
> >>>>>> compilado mas não está em uso) e está funcionando à 128 dias sem
> parar e
> >>>>>> com 7 jails.
> >>>>> Ah sim, o fato de ser experimental não quer dizer que absolutamente
> não
> >>>>> irá funcionar. Serve mais pra te alertar que pode dar problema, que
> não
> >>>>> é estável.
> >>>>>
> >>>>> É que do jeito que o Marcelo colocou ficou parecendo que o FreeBSD
> 9.1
> >>>>> não está estável, sendo que ele optou por usar algo experimental.
> Quando
> >>>>> você faz essa escolha está sujeito as consequências :)
> >>>>>
> >>>>> []s
> >>>> Sim é mesmo Renato, mas tipo foi mais como exemplo. O OSPF também dava
> >>>> uns paus no curso que fiz na FreeBSD Brasil e que parecia de longa
> data
> >>>> o bug. O uso do ntfs com leitura e escrita também dava um monte de
> >>>> kernel panic. Não sei agora como está.
> >>> OSPF é um pacote não? Então não dá pra dizer o que SO tá instável por
> >>> conta de um pacote. NTFS pra leitura e escrita é um módulo nativo do
> >>> kernel ou é FUSE? Se for FUSE eu acho que cai no mesmo caso do OSPF.
> >>>
> >>>> Teve kernel panic que descobri também no geom mas esse foi corrigido
> >>>> rápido. Tenho tido hardwares rebootando do nada e sem gerar qualquer
> >>>> dump no /var/crash. Esse problema do crash vi alguns relatos também,
> que
> >>>> mesmo habilitando não funcionava em alguns casos. Mas tipo isso é só
> uma
> >>>> preocupação que estou tendo. Todos os meus servidores em produção
> estão
> >>>> rodando muito bem e sem reboots.
> >>>> Meu medo é termos algo que aconteceu na versão 5.0, que eu não
> >>>> vivenciei, mas que muitos tiveram problemas.
> >>> Esses crashs estranhos e sem explicação são coisas que têm que ser
> >>> diagnosticadas, e em muitos casos no final o problema tá no hardware.
> >>> Sugiro habilitar debugs no kernel e ver se consegue algo.
> >>>
> >>> Sobre o que aconteceu no 5.0, foi uma história bem diferente, e
> acredito
> >>> que o time aprendeu com o erro, uma versão com tantas mudanças como
> >>> ocorreu do 4 pro 5 não deve acontecer mais.
> >>>
> >> Quando um mero pacote ou software derruba o S.O. não é uma falha grave
> do S.O?
> > Isso é relativo, o FUSE por exemplo é um pacote que compila um módulo de
> > kernel, não vejo o fato de um módulo de kernel derrubar o SO como algo
> > falho do SO. Mas fica difícil falar pois não tenho detalhes sobre os
> bugs.
> >
> Opa Renato,
>
> Esse lance do fuse depois que fiz um pr, rapidamente foi corrigido. Era
> um bug sinistro mesmo. Porque era só montar a partição ntfs e começar à
> copiar para dar um panic e o sistema reiniciar. Mas acho que pouca gente
> devia estar usando esse cara porque o panic era instantâneo mesmo. Bem
> esse foi resolvido rápido.
> Agora esse race condition que é brabo porque ele está lá em algum lugar
> e tipo não posso colocar um server e pendurar 4000 assinantes nele
> sabendo que se alguém na minha rede fizer um ataque de login incorreto
> por um certo tempo, vai causar um kernel panic derrubando os meus 4000
> assinantes. Eu fiz uma atualização ontem no sistema e parece que não
> ocorreu mais mas ainda quero testar mais e ter certeza.
> Vou testar com o 8.3 ainda pra saber se isso é só do 9.1. Não tenho o
> que reclamar do Freeba todos os meus servidores estão 100% estáveis. Só
> tive mesmo esses pipoucos estranhos em alguns testes e fiquei preocupado.
>
> Grande abraço à todos
>
>
>
>
Bom pessoal, já que o tópico mudou de ALTQ + INTEL para FreeBSD
estabilidade, gostaria de compartilhar meu ponto de vista quanto ao
9.1-RELEASE.

Estou trabalhando há mais de 1 ano em um produto que usa FreeBSD como base.
FreeBSD é ótimo, robusto e etc; como todos sabem.

Agora vamos para o lado ruim, e esse lado ruim é realmente ruim mesmo.

1) Multirouting table e routing.
- FIB não funciona bem no FreeBSD, tive que fazer várias alterações para
fazer o FIB funcionar sem ter que iniciar daemons com setfib! Como eu
expliquei em outro email; quero que o tráfego que entra via ix0 saia via
ix0 independente da rota que tiver para a subrede na tabela FIB 0. No LINUX
isso funciona a séculos.
- Tive que modificar muita coisa para fazer isso funcionar, ficou lindo;
não submeti de volta para o FreeBSD por 2 motivos:
  1.1) NDA na empresa onde trabalho; até que bem conversadinho eles liberam.
  1.2) O desenvolvimento do FreeBSD é lento, especialmente no "SRC",
pessoal muito ocupado, existência de grupinhos e etc.

NOTA: Um patch que enviei em 2008 para o IPFW, foi comitado alguns meses
atrás.

2) Routing.
- O código responsável pelo roteamento no FreeBSD é uma bagunça, não
funciona direito e é cheio de bugs. Praticamente uma caixa de pandora,
pedaços de código em tudo quanto é canto, mal documentado e etc.
- Ninguém ou quase ninguém tem coragem de abrir/tocar na "caixa de pandora".

3) Intel Drivers.
- As vezes no site da INTEL o driver é mais novo que no FreeBSD, e no
FreeBSD temos 4 desenvolvedores da INTEL e um deles trabalha diretamente
nos drivers de rede INTEL.
- Depois que eu enviei um patch com a atualização do driver ixgbe, o
desenvolvedor meio que deu risada, dizendo que ele é o mantenedor do driver
e que eu não precisava enviar a atualização. Minha resposta foi: -- Então
atualiza na base porra. Outros desenvolvedores também reclamaram sobre esse
problema do driver antigo na base. No final o driver foi atualizado no
CURRENT e no 9-STABLE.

PATCH: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/176281

4) Alguém sabe como o radix_mpath funciona? "EU SEI!".
- Não existe documentação para o radix_mpath, tive que ler o código para
entender como funciona. E detalhe que, não funciona como deveria, mas para
MULTIPLES ROUTING and ROUTING FAIL OVER or ROUTING LOAD BALANCE ele
funciona bem.

5) ALTQ.
- É uma vergonha não ter uma API genérica para que os drivers de rede usem
o ALTQ.
- IXGBE e GBE estão quebrados no 9.x por conta da falta de uma API, foram
atualizados os drivers e várias chamadas do ALTQ foram removidas e agora
são incompatíveis, pois esses novos drivers usam MULTIPLES QUEUES.

6) PCIe(Non-Transparent-Bridge).
- Foi inserido algumas semanas atrás esse driver pela INTEL, estou em
contato com eles há quase 1 ano, tentando ajudar, oferecendo código e etc.
Resultado, meu driver já está pronto há mais de 8 meses e eu uso DMA ao
contrário de usar memcpy() como eles(sabem que é errado) estão fazendo.

7) Apenas como curiosidade.
Vocês sabiam que "ifconfig <iface> 192.168.1.1/24" é errado? O que eu quero
dizer é que, para configurar um endereço IPv4, nós deveriamos fazer desta
forma "ifconfig <iface> inet 192.18.1.1/24", mas não fazemos por conta de
um bug que introduziu esta opção para nós sem ter que usar "inet" e isso
também quebrou um monte de coisa ou forçou muita gente a fazer um monte de
gambiarra em outras partes de código, especialmente na parte de roteamento.

FreeBSD é bom? Sim, ele é!
É uma maravilha? Não, nem fodendo!
Abrir bug report e enviar patches resolve? Bom, prefiro não entrar em
detalhes!!

"""Porém, continuem enviando patches, abrindo bug reports, enviando emails
direto para os maintainers, isso ajuda bastante!!"""

Eu vou morrer defendendo o FreeBSD, enviando patches, desenvolvendo,
fazendo o possível para melhorar o SO! Mas o FreeBSD não é aquela
maravilha, e mais do que nunca está precisando de "CARNE FRESCA" para o
time de desenvolvimento.

Abraços.
-- 
Marcelo Araujo
araujo em FreeBSD.org