Episode Details

Lo primero: no quiero arrancar este episodio sin dar las gracias como se merece a IPng Networks y, en especial, a Pim Van Pelt. Tuve la suerte de compartir un café con él en el ESNOG de Barcelona hace un par de años, y te das cuenta en cinco minutos de que no solo sabe una barbaridad, sino que además tiene la capacidad de explicar cosas muy complejas de forma clara y honesta. Su trabajo y su manera de compartir conocimiento han ayudado a muchos a entender qué demonios está pasando realmente dentro del plano de datos moderno. Este episodio, en buena parte, nace de esa base de conocimiento que otros han currado antes.

Y ahora sí, como dice Felipe, vamos al lío.

Este episodio es la primera parte de un análisis bastante serio —pero contado como lo contaría alguien que lleva más de veinte años en telecomunicaciones— sobre algo que casi todos hemos sufrido alguna vez: tienes un servidor Linux con buena CPU, buena RAM, tarjetas modernas… y de repente empieza a perder paquetes. O aparece jitter. O la latencia hace cosas raras. Y miras la CPU global y está al 20 %. Y piensas: “¿Pero qué está pasando aquí?”

La clave no está en la potencia bruta. Está en el modelo de procesamiento.

El stack de red del kernel Linux está pensado para ser generalista. Tiene que servir para servidores web, bases de datos, firewalls, virtualización, mil aplicaciones a la vez. Cada paquete que entra genera interrupciones, estructuras dinámicas, validaciones, decisiones del scheduler… Todo eso funciona muy bien cuando la carga es razonable.

Pero cuando empiezas a hablar en serio de paquetes por segundo, la historia cambia. No tanto por los gigabits, sino por los pps. Empiezan las invalidaciones de caché, la carga se concentra en una o dos colas, aparecen microbursts que no se absorben bien y el sistema empieza a comportarse de forma poco predecible. No es que Linux “no pueda”. Es que no está optimizado exclusivamente para forwarding masivo.

Aquí es donde entra el enfoque vectorial.

En vez de tratar cada paquete como si fuera un evento único que requiere atención inmediata, el modelo vectorial los agrupa en lotes y los procesa en bloque. Se reducen transiciones, se mantiene la caché caliente y la CPU hace lo que mejor sabe hacer: ejecutar el mismo código repetidamente sobre datos similares.

En lugar de vivir a base de interrupciones, los cores dedicados al plano de datos hacen polling continuo. Sí, están preguntando todo el rato si hay trabajo. A primera vista parece poco eficiente, pero cuando te mueves en millones de paquetes por segundo, el coste del polling es mucho menor que el de gestionar millones de interrupciones.

Sobre esta idea se construye VPP, el Vector Packet Processor. Es un plano de datos en espacio de usuario que, apoyándose en DPDK, toma control directo de las interfaces de red. Organiza el procesamiento como un grafo de nodos: uno clasifica capa 2, otro analiza IP, otro hace el lookup en la FIB, otro reescribe cabeceras, otro aplica ACLs… y todo eso lo hace sobre vectores de buffers ya reservados en hugepages. No hay malloc por paquete. No hay estructuras que se creen y destruyan constantemente.

Y aquí ya nos metemos en terreno físico de verdad: cachés L1, L2, L3, predicción de saltos, TLB, hugepages… Esto no va solo de “configurar BGP”. Va de entender cómo funciona la CPU por dentro. Si ejecutas el mismo código sobre datos contiguos, la caché trabaja a tu favor. Si accedes a memoria del otro socket NUMA, el coste sube. Si no alineas bien colas RSS con workers, puedes saturar un core mientras el de al lado está mirando.

Todo cuenta: CPU, memoria, NIC y cómo lo configuras.

Otro punto importante es que esto no elimina el kernel. Lo separa. El forwarding masivo lo hace el motor vectorial en el plano de datos, pero el plano de control sigue en Linux. Bird o FRR gestionan BGP, OSPF, lo