Placas De Rede Ethernet

Instalar placas de rede ethernet no Linux: o que funciona de verdade

A maioria das pessoas tenta rodar o lspci, acha o chipset e vai caçar o driver no Google sem saber exatamente onde procurar. Esse método funciona às vezes. Na maior parte das vezes, gasta vinte minutos procurando um link para um repositório abandonado que não corresponde à versão do seu kernel. Eu prefiro começar verificando se o kernel já carrega o módulo nativo antes de fazer qualquer coisa. Vou explicar do jeito que eu faço quando chego em um servidor que precisa de uma interface nova. Primeiro, abro o terminal e rodei o comando lspci -nn | grep -i ethernet. O resultado mostra o ID do vendor e do device entre colchetes, algo como [14e4:1680]. Esse par é o que importa. Com ele, você entra no site do fabricante ou num banco de dados como o Linux Hardware Project e descobre qual driver o kernel usa. Se o driver já existir no seu módulo atual, é só carregar com modprobe. Não precisa baixar nada. O problema é que muitos usuários avançados pulam esse passo. Eles veem uma placa Realtek ou Intel e instalam um driver da página do fabricante mesmo tendo um módulo nativo. Isso costuma causar conflito. Já vi casos onde uma Intel I210, que roda perfeitamente com igb, passou a dar queda de link intermitente depois que alguém instalou um driver antigo baixado diretamente do site da Intel. A solução foi remover o driver compilado manualmente, voltar pro módulo do kernel, e aplicar um update do firmware da NIC via ipmitool. Levei cerca de meia hora pra resolver isso porque passei duas horas na direction errada antes de perceber.

Quando o driver não está no kernel, a situação muda. Você precisa compilar. A maioria dos drivers que não vêm no tree do kernel segue o padrão make && sudo make install. Mas tem uma pegadinha: o DKMS. Se você usar DKMS, o driver se reconstrói automaticamente quando você atualiza o kernel. Isso evita aquele pesadelo de ter que recompilar tudo manualmente depois de um update. Configure o DKMS assim: copie os arquivos do driver para /usr/src/-, crie um arquivo dkms.conf com os parâmetros corretos, e rode dkms add e dkms build. O tempo de compilação varia entre dois e cinco minutos, dependendo do hardware. Placas com suporte a RSS e multi-queue levam mais tempo porque geram mais código. Outra coisa que poucas pessoas consideram: a versão do seu kernel define o quão moderna precisa ser a placa que você compra. Placas que exigem driver fora do kernel geralmente são de fabricantes menores. Intel e Mellanox são diferentes. Os chips da Intel entram direto no kernel. A série i210, i225, i226 usa igb ou ice. A partir da série E810, você precisa do driver ice. Se você estiver rodando um kernel LTS mais antigo, pode não ter suporte nativo para modelos recentes. Verifique a saída de lsmod | grep igb antes de comprar qualquer coisa. Se o módulo existir, você está dentro da curva. Também existe o caso das placas USB ethernet, que são uma categoria completamente diferente. Elas usam drivers como r8152 ou cdc_ether. A performance é limitada pela bandwidth do USB e pela latência do controlador. Para servidores, eu nunca recomendo USB. Para estações de trabalho e laptops com porta Thunderbolt, funciona. O problema é que drivers USB ethernet muitas vezes não herdam as opções avançadas de offloading que as PCI express tem. Se você precisa de TSO, GSO, ou Gro, verifique com ethtool -k. A interface USB pode não suportar tudo.

A configuração de performance vem depois da instalação. Use ethtool para ajustar settings. Coisas como autonegotiation, speed, duplex, e ring buffer fazem diferença real em ambientes com alto throughput. O commando ethtool -S mostra estatísticas da placa. Se você ver drops aumentando constantemente, aumente o ring buffer com ethtool -G. Mas cuidado: aumentar demais consome memória sem benefício proporcional. O ideal é testar com iperf3 e verificar a taxa de erro. Placas de rede ethernet precisam ser consideradas como parte de um sistema inteiro, não como componentes isolados. Firmware desatualizado, driver incompatível, e configuração incorreta de IRQ affinity são os três problemas que mais vejo em produção. Um servidor que recebeu uma atualização de kernel sem reconstruir um driver DKMS parado de funcionar completamente. Outro teveIRQs distribuídas de forma desigual entre cores, causando gargalo em apenas um processador. Verifique tudo com afd, ethtool, e ip -s link antes de considerar que a instalação está concluída. Se você está em um ambiente com requisitos de baixa latência, considere também o DPDK. Ele contorna o stack tradicional do kernel e usa drivers userspace. Não é solução para todo mundo. Introduz complexidade extra e requer hardware compatível. Mas para workloads como router virtualizado ou sniffing de alta performance, faz diferença de milissegundos para microssegundos. Isso é algo que você descobre depois de tentar resolver um problema de latência no kernel e não conseguir.