Los mapas: estado compartido entre kernel y usuario

Un programa eBPF nace y muere en cada disparo: se ejecuta cuando su evento ocurre y no recuerda nada de la vez anterior. Sin memoria persistente sería inútil para contar, medir o correlacionar. Los mapas son esa memoria. Son estructuras de datos que viven en el kernel, sobreviven entre invocaciones y —esto es lo decisivo— pueden leerse y escribirse tanto desde el programa en anillo 0 como desde un proceso en espacio de usuario. Con una sola abstracción, eBPF resuelve a la vez el problema del estado y el de la comunicación entre los dos lados del sistema.

Estado y puente en una sola abstracción

Un mapa es un almacén clave-valor gestionado por el kernel. Se declara en el propio programa con metadatos BTF, y libbpf lo crea al cargar. Desde el lado del kernel se accede con auxiliares —bpf_map_lookup_elem, bpf_map_update_elem, bpf_map_delete_elem—; desde el lado del usuario, con la llamada bpf() o, en algunos tipos, con mmap. El mismo mapa es visible por ambos, y ahí reside su poder: el programa acumula datos en anillo 0 y el proceso los lee sin copias ni bloqueos costosos.

struct {
	__uint(type, BPF_MAP_TYPE_HASH);
	__uint(max_entries, 10240);
	__type(key, u32);
	__type(value, u64);
} syscalls_por_pid SEC(".maps");

flowchart LR
P[programa eBPF en anillo 0] -->|bpf_map_update_elem| M[mapa en el kernel]
M -->|bpf_map_lookup_elem| P
U[proceso en espacio de usuario] -->|syscall bpf o mmap| M
M -->|lectura sin copia| U

Hash y array: los dos mapas fundamentales

El mapa hash admite claves arbitrarias y crece dinámicamente hasta su tope; es el que usarías para contar por PID, por dirección IP o por nombre de función. El mapa array usa un índice entero como clave, está preasignado por completo y es más rápido y predecible, ideal para tablas de configuración o histogramas de tamaño fijo. Un contador de llamadas al sistema por proceso, sobre un mapa hash:

SEC("tp/raw_syscalls/sys_enter")
int cuenta(void *ctx)
{
	u32 pid = bpf_get_current_pid_tgid() >> 32;
	u64 *n = bpf_map_lookup_elem(&syscalls_por_pid, &pid);

	if (n)
		__sync_fetch_and_add(n, 1);     /* incremento atómico sobre el valor */
	else {
		u64 uno = 1;
		bpf_map_update_elem(&syscalls_por_pid, &pid, &uno, BPF_ANY);
	}
	return 0;
}

Fíjate en un detalle sutil: bpf_map_lookup_elem devuelve un puntero directo al valor dentro del kernel, no una copia. Por eso puedes modificarlo en el sitio con un incremento atómico. Pero también por eso, si dos CPUs tocan la misma entrada a la vez, hay una carrera —y el incremento atómico es la forma mínima de evitar que se pierdan cuentas—.

Per-CPU: evitar carreras repartiendo el estado

La solución elegante a esa contención es no compartir. Las variantes BPF_MAP_TYPE_PERCPU_HASH y BPF_MAP_TYPE_PERCPU_ARRAY mantienen una copia del valor por cada CPU. Cada núcleo actualiza la suya sin bloqueos ni operaciones atómicas y sin hacer rebotar la línea de caché entre procesadores; el espacio de usuario suma después las copias para obtener el total:

struct {
	__uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
	__uint(max_entries, 1);
	__type(key, u32);
	__type(value, u64);
} bytes_totales SEC(".maps");

SEC("xdp")
int contabiliza(struct xdp_md *ctx)
{
	u32 clave = 0;
	u64 len = ctx->data_end - ctx->data;
	u64 *acc = bpf_map_lookup_elem(&bytes_totales, &clave);

	if (acc)
		*acc += len;    /* sin átomos: esta CPU es dueña de su copia */
	return XDP_PASS;
}

En un XDP que procesa millones de paquetes por segundo, la diferencia entre un contador compartido con átomos y un contador per-CPU es la diferencia entre saturarse y volar. El coste es que la lectura debe agregar; la ganancia es que la escritura, en el camino caliente, no compite con nadie.

El ring buffer: el flujo de eventos al espacio de usuario

Los contadores resumen; a veces necesitas el evento entero. Para transmitir un flujo de registros del kernel al usuario, el tipo BPF_MAP_TYPE_RINGBUF —incorporado en Linux 5.8— es hoy la respuesta canónica. Es un búfer circular único de varios productores y un consumidor, que preserva el orden de los eventos, notifica por epoll y desperdicia mucha menos memoria que el antiguo búfer per-CPU de perf. Su API reserva espacio, lo rellena y lo confirma:

struct evento { u32 pid; u8 comm[16]; };

struct {
	__uint(type, BPF_MAP_TYPE_RINGBUF);
	__uint(max_entries, 256 * 1024);   /* tamaño en bytes, potencia de dos */
} eventos SEC(".maps");

SEC("tp/sched/sched_process_exec")
int al_exec(void *ctx)
{
	struct evento *e = bpf_ringbuf_reserve(&eventos, sizeof(*e), 0);
	if (!e)
		return 0;                              /* búfer lleno: se descarta */

	e->pid = bpf_get_current_pid_tgid() >> 32;
	bpf_get_current_comm(&e->comm, sizeof(e->comm));
	bpf_ringbuf_submit(e, 0);                      /* visible ya para el usuario */
	return 0;
}

Del lado del usuario, libbpf ofrece un lector que despierta con epoll y entrega cada registro a una función:

static int al_evento(void *ctx, void *data, size_t len)
{
	const struct evento *e = data;
	printf("exec pid=%u comm=%s\n", e->pid, e->comm);
	return 0;
}

struct ring_buffer *rb = ring_buffer__new(bpf_map__fd(skel->maps.eventos),
					  al_evento, NULL, NULL);
while (!parar)
	ring_buffer__poll(rb, 100 /* ms */);