Atteindre un débit de plusieurs dizaines de gigabits par seconde dans les passerelles VPN en espace utilisateur impose de repenser la transition des paquets entre la carte réseau physique (NIC) et le moteur applicatif. Traditionnellement, les tunnels logiciels développés en Go, Rust ou C interagissent avec le système d'exploitation par le biais d'interfaces virtuelles TUN/TAP (/dev/net/tun). Bien que le pilote TUN assure une compatibilité universelle, il engendre des pénalités structurelles considérables : chaque paquet requiert des changements de contexte entre le noyau et l'espace utilisateur, l'allocation de la structure de métadonnées struct sk_buff et une copie mémoire via copy_to_user().

À des débits de ligne de 10 Gbps ou 40 Gbps, ces opérations sollicitent excessivement les bus mémoire et saturent les caches CPU, limitant le débit d'un cœur isolé à environ 1,5 million de paquets par seconde (Mpps). Si le kit DPDK (Data Plane Development Kit) élimine ces goulets d'étranglement en prenant le contrôle exclusif du matériel, il isole complètement la carte réseau du système d'exploitation, rendant inopérants les outils d'administration Linux standards (iproute2, nftables, tcpdump) ainsi que les services hébergés tiers.

La famille d'adresses Linux XDP (AF_XDP, appelée également XSK) résout ce compromis. En combinant la redirection de paquets eBPF au niveau du pilote avec des pools de mémoire préalloués en espace utilisateur (UMEM), AF_XDP offre une transmission zero-copy directe vers l'application tout en préservant l'intégrité de la pile réseau Linux.

Coût architectural : chemins de données TUN/TAP et AF_XDP

Pour mesurer l'écart de performance, observons le cycle de vie d'un paquet VPN chiffré dans chacun des deux paradigmes :

[Chemin de données conventionnel TUN/TAP]
Anneau RX NIC ──> alloc_skb() ──> Pile IP noyau / Netfilter ──> Pilote TUN
                                                                     │
                   Changement de contexte + Copie (copy_to_user) <───┘
                                      │
                                      ▼
                        Application VPN utilisateur (Déchiffrement)

─────────────────────────────────────────────────────────────────────────

[Chemin de données zero-copy AF_XDP]
Anneau RX NIC ──> Accès DMA direct ──> Bloc mémoire UMEM préalloué
                         │
            Filtre XDP: bpf_redirect_map()
                         │
                         ▼ (Zero-copy, transfert sans verrou de descripteurs)
               Moteur VPN utilisateur (Déchiffrement direct en mémoire)

Dans la chaîne de traitement AF_XDP, le noyau n'alloue plus de structures struct sk_buff. Le contrôleur DMA de la carte réseau transfère les trames Ethernet directement dans une région mémoire contiguë préenregistrée (UMEM). Un programme eBPF attaché au point d'ancrage du pilote (BPF_PROG_TYPE_XDP) vérifie uniquement les en-têtes du paquet. Si le paquet est destiné au service VPN (port UDP désigné ou signature de session), l'instruction bpf_redirect_map(&qidconf_map, queue_id, 0) l'oriente vers la socket XSK. Les autres flux réseau retournent XDP_PASS et rejoignent normalement la pile IP Linux.

Architecture UMEM et les quatre files circulaires sans verrou

La pièce maîtresse d'une implémentation AF_XDP est l'UMEM : une zone de mémoire virtuelle contiguë déclarée auprès du noyau via l'appel système setsockopt(..., SOL_XDP, XDP_UMEM_REG, ...). L'UMEM est subdivisée en trames de taille fixe (généralement 2048 ou 4096 octets).

L'échange d'informations entre l'espace utilisateur et le pilote s'articule autour de quatre anneaux circulaires sans verrou à producteur unique et consommateur unique (SPSC) :

  1. Anneau de remplissage (Fill Ring - Espace utilisateur produit -> Noyau consomme) : L'application transmet les adresses des trames UMEM libres prêtes à accueillir les paquets entrants.
  2. Anneau de réception (Rx Ring - Noyau produit -> Espace utilisateur consomme) : À l'arrivée d'un paquet, le pilote dépose un descripteur (décalage mémoire et longueur de trame) dans l'anneau pour traitement applicatif.
  3. Anneau de transmission (Tx Ring - Espace utilisateur produit -> Noyau consomme) : Pour émettre un paquet chiffré sortant, l'application soumet les descripteurs correspondants dans l'anneau de transmission.
  4. Anneau de complétion (Completion Ring - Noyau produit -> Espace utilisateur consomme) : Dès que la carte réseau a expédié la trame sur le réseau, le pilote reporte son adresse dans l'anneau de complétion afin que le tampon soit réutilisé immédiatement.

Ces anneaux fonctionnant par simple incrément atomique de pointeurs sans aucun verrou d'exclusion mutuelle, les cœurs CPU peuvent traiter les paquets par lots de 32 ou 64 trames sans contention inter-processus.

Implémentation noyau : redirection XDP au niveau pilote

Le volet noyau repose sur un classificateur eBPF concis lié à l'interface physique :

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/udp.h>
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_XSKMAP);
    __uint(max_entries, 64);
    __type(key, __u32);
    __type(value, __u32);
} qidconf_map SEC(".maps");

SEC("xdp")
int xdp_vpn_redirect(struct xdp_md *ctx)
{
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    
    /* Contrôle des limites : en-tête Ethernet minimal */
    if (data + sizeof(struct ethhdr) > data_end)
        return XDP_PASS;
        
    struct ethhdr *eth = data;
    if (eth->h_proto != __constant_htons(ETH_P_IP))
        return XDP_PASS;
        
    struct iphdr *iph = data + sizeof(struct ethhdr);
    if ((void *)(iph + 1) > data_end || iph->protocol != IPPROTO_UDP)
        return XDP_PASS;
        
    struct udphdr *udph = (void *)iph + (iph->ihl * 4);
    if ((void *)(udph + 1) > data_end)
        return XDP_PASS;
        
    /* Redirection directe des paquets du port VPN vers la socket AF_XDP */
    if (udph->dest == __constant_htons(51820)) {
        return bpf_redirect_map(&qidconf_map, ctx->rx_queue_index, XDP_PASS);
    }
    
    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

Ce code s'exécute en quelques nanosecondes dans le contexte d'interruption du pilote. Les trames VPN atteignent directement les anneaux utilisateurs tandis que le trafic SSH, la supervision et les sessions BGP poursuivent leur transit via la pile noyau standard.

Moteur applicatif : enregistrement UMEM et scrutation zero-copy

Côté utilisateur, l'initialisation du travailleur AF_XDP requiert l'allocation de mémoire contiguë alignée via posix_memalign(), la configuration des paramètres UMEM et la liaison de la socket avec les indicateurs de zero-copy :

#include <xdp/xsk.h>
#include <stdlib.h>
#include <sys/socket.h>

#define NUM_FRAMES 4096
#define FRAME_SIZE 2048

struct xsk_umem_info {
    struct xsk_ring_prod fq;
    struct xsk_ring_cons cq;
    struct xsk_umem *umem;
    void *buffer;
};

int init_af_xdp_socket(struct xsk_umem_info *umem_info, const char *ifname, int queue_id)
{
    struct xsk_socket_config xsk_cfg;
    struct xsk_umem_config umem_cfg = {
        .fill_size = NUM_FRAMES,
        .comp_size = NUM_FRAMES,
        .frame_size = FRAME_SIZE,
        .frame_headroom = XDP_PACKET_HEADROOM,
        .flags = 0
    };
    
    /* Allocation d'une zone mémoire alignée */
    posix_memalign(&umem_info->buffer, getpagesize(), NUM_FRAMES * FRAME_SIZE);
    
    /* Enregistrement du pool UMEM auprès du noyau */
    xsk_umem__create(&umem_info->umem, umem_info->buffer, 
                     NUM_FRAMES * FRAME_SIZE, &umem_info->fq, 
                     &umem_info->cq, &umem_cfg);
                     
    xsk_cfg.rx_size = NUM_FRAMES;
    xsk_cfg.tx_size = NUM_FRAMES;
    xsk_cfg.libbpf_flags = 0;
    xsk_cfg.xdp_flags = XDP_FLAGS_UPDATE_IF_NOEXIST | XDP_FLAGS_DRV_MODE;
    xsk_cfg.bind_flags = XDP_ZEROCOPY | XDP_USE_NEED_WAKEUP;
    
    return 0;
}

Grâce à l'indicateur XDP_USE_NEED_WAKEUP, l'application évite les appels système superflus. Le noyau n'exécute le cycle de réveil du pilote que lorsque l'espace utilisateur signale explicitement un besoin de ravitaillement de la file matérielle.

Déploiement en production sur les passerelles RiceGuard Anycast

RiceGuard déploie cette architecture AF_XDP au cœur de son réseau Anycast distribué pour garantir une performance stable sous forte charge multi-clients :

  • Densité de commutation élevée : Les nœuds bi-processeurs RiceGuard atteignent un débit supérieur à 24 millions de paquets par seconde (Mpps), soit un saut d'échelle net par rapport aux pilotes TUN historiques.
  • Latence de transit millimétrique : En éliminant la contention de verrous noyau et les copies de tampons, la latence de traitement des paquets reste inférieure à 1,2 microseconde.
  • Exploitation système simplifiée : L'interface physique demeurant un adaptateur réseau Linux standard, les démons de routage dynamique BGP Anycast et les outils de métrologie fonctionnent sans modification.

En exploitant AF_XDP et les anneaux UMEM zero-copy, RiceGuard propulse le traitement des paquets chiffrés à la vitesse physique du réseau tout en maintenant l'intégralité des fonctionnalités du système Linux.