[FUG-BR] ALTQ + Intel Drivers.

[Renato Botelho]

On 05/22/2013 12:06 AM, Marcelo Araujo wrote:
> 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.

É por conta dessa lentidão na revisão de PRs/patches que muitas empresas
acabam contratando committers pra que as coisas aconteçam de forma mais
rápida. Isso é um ponto muito ruim mas acho que não existe uma solução
rápida, pra isso melhorar teríamos que ter mais pessoas trabalhando no src.

O que eu vejo o pessoal fazendo pra acelerar um pouco os commits é
enviar o patch pra lista (-current, -stable, -net) e assim mais gente
pode ver facilmente a utilidade do mesmo, o que acaba forçando o commit
a acontecer mais rapidamente.

-- 
Renato Botelho