Les architectures réseau d'entreprise contemporaines et les réseaux de transit cloud exigent que les passerelles VPN concentrent et traitent plusieurs dizaines de millions de paquets par seconde (Mpps) sur des interfaces 40 GbE et 100 GbE. Face à de tels volumes de trafic, les piles réseau traditionnelles des systèmes d'exploitation atteignent une limite infranchissable : le coût CPU par paquet.

Chaque fois qu'un adaptateur de tunnel virtuel Linux standard (tel que TUN/TAP, IP-in-IP, GRE ou VXLAN) procède à l'encapsulation ou au décapsulage du trafic, le noyau alloue une structure struct sk_buff de 240 octets, recopie ou agrandit les zones mémoires via pskb_expand_head() et traverse des dizaines de couches de filtrage et de gestion de files d'attente. Même avec des optimisations matérielles poussées, ce modèle traditionnel sature un cœur CPU dès 1,5 à 2,5 Mpps.

L'association d'eXpress Data Path (XDP) et de la fonction d'assistance bpf_xdp_adjust_head() redéfinit totalement cette approche. En intervenant directement au cœur de la boucle de scrutation des interruptions (NAPI) du pilote de carte réseau avant toute allocation de tampon système, XDP permet aux ingénieurs d'encapsuler et de décapsuler les paquets en mode zero-copy au débit de ligne, dépassant les 14 Mpps sur un seul cœur CPU.

Comparaison entre l'encapsulation noyau classique et le fastpath XDP :

Modèle d'encapsulation noyau classique (Forte consommation CPU) :
Liaison physique ──> DMA Carte réseau ──> Allouer sk_buff (240B) ──> Netfilter PREROUTING
                                                                            │
                                                                            ▼
[Démon VPN / Périphérique virtuel] ◄── pskb_expand_head() (Réallocation) ◄── Routage
           │
           ▼ (Ajout en-têtes IP + UDP externes)
Réinjection dans la pile ──> Netfilter POSTROUTING ──> File qdisc ──> Anneau TX Carte
Plafond de débit : ~2,0 Mpps par cœur CPU

Fastpath zero-copy XDP dans le pilote réseau :
Liaison physique ──> DMA Carte réseau ──> Boucle NAPI RX ──> Exécution programme XDP
                                                                    │
                                                                    ▼
                                                       bpf_xdp_adjust_head(ctx, -delta)
                                                       (Extension dans l'anneau DMA !)
                                                                    │
                                                                    ▼
                                                       Écriture en-têtes IP + UDP externes
                                                                    │
                                                                    ▼
                                                       Action : XDP_TX / bpf_redirect_map()
                                                       (Départ immédiat sans créer de sk_buff !)
Débit effectif : ~14,5 Mpps par cœur CPU (Débit de ligne matériel !)

Les limitations structurelles des couches de tunnel classiques

Pour comprendre l'ampleur du gain procuré par XDP, il convient d'analyser les mécanismes internes de la pile réseau Linux standard :

  1. Poids de l'allocation des descripteurs sk_buff : À chaque paquet entrant, le pilote alloue un objet struct sk_buff pour encadrer la charge utile brute. Cette création implique la réinitialisation de la mémoire, la gestion de compteurs atomiques de référence et l'assignation de métadonnées d'horodatage.
  2. Manque d'espace en tête (Headroom Starvation) : Les pilotes de tunnels virtuels doivent insérer des en-têtes supplémentaires (Ethernet, IPv4/IPv6 et UDP). Si la zone tampon initiale fournie par le pilote ne dispose pas d'une réserve suffisante en tête, le noyau déclenche pskb_expand_head(). Cette opération force une réallocation complète de la mémoire et une copie des données, détruisant la localité du cache processeur.
  3. Traversées redondantes des sous-systèmes : Le paquet traverse le moteur de réception IP, le suivi de connexions (nf_conntrack), l'adaptateur de tunnel virtuel, pour ensuite être réinjecté en tant que paquet encapsulé et reparcourir l'intégralité des filtres de sortie.

Sous un flux soutenu, les cœurs CPU peuvent consacrer jusqu'à 70 % de leurs cycles d'horloge à ces tâches de gestion mémoire et de synchronisation plutôt qu'au traitement réel des flux applicatifs.

Fonctionnement interne de bpf_xdp_adjust_head dans le pilote

XDP s'exécute au point d'entrée le plus bas de la pile logicielle. Le paquet se présente comme un bloc de mémoire physique continue décrit par la structure struct xdp_buff :

struct xdp_buff {
    void *data;             /* Pointeur de début des données */
    void *data_end;         /* Pointeur de fin des données */
    void *data_meta;        /* Zone de métadonnées précédant data */
    void *data_hard_start;  /* Début physique de la page mémoire */
    struct xdp_rxq_info *rxq;
    struct xdp_mem_info mem;
    u32 flags;
};

Les pilotes modernes (comme mlx5, i40e, ixgbe ou virtio_net) réservent un espace libre en amont (habituellement fixé à XDP_PACKET_HEADROOM = 256 octets) entre data_hard_start et data.

Déplacement des frontières du paquet avec bpf_xdp_adjust_head

Le noyau Linux fournit la fonction d'assistance BPF :

long bpf_xdp_adjust_head(struct xdp_md *xdp_md, int delta);

Le paramètre delta gouverne le repositionnement de la frontière mémoire :

  • Delta négatif (delta < 0) — Encapsulation : Soustraire des octets déplace le pointeur ctx->data vers l'arrière en direction de data_hard_start, étendant le paquet dans la réserve libre du pilote. Cela crée un espace mémoire continu où le programme eBPF peut directement écrire les nouveaux en-têtes réseau et de tunnel.
  • Delta positif (delta > 0) — Décapsulage : Ajouter des octets fait avancer ctx->data, ce qui retire instantanément les en-têtes externes (Ethernet, IP et UDP) et expose directement la charge utile interne au noyau ou aux tables de routage.
Géométrie mémoire de xdp_buff lors de l'expansion d'en-tête :

Avant bpf_xdp_adjust_head (Paquet brut reçu) :
[ data_hard_start ] ──[ Réserve disponible (256B) ]──> [ data ]───────[ data_end ]
                                                         │              │
                                                         └─ IP interne ─┘

Après bpf_xdp_adjust_head(ctx, -28) :
[ data_hard_start ] ──[ Réserve restante (228B) ]──> [ data ]─────────[ data_end ]
                                                      │                │
                                                      ├─ Nouvel IP (20B)
                                                      ├─ Nouvel UDP (8B)
                                                      └─ Charge interne ┘

L'invariant de sécurité du vérificateur eBPF : Invalidité des pointeurs

Une règle architecturale essentielle lors de la programmation d'encapsulation XDP concerne le vérificateur de sécurité (BPF Verifier) du noyau Linux.

Dès que bpf_xdp_adjust_head() s'exécute avec succès, l'adresse mémoire physique de ctx->data change impérativement. En conséquence, le vérificateur invalide sur-le-champ tous les pointeurs précédemment calculés et toutes les preuves de vérification de limites.

Toute tentative d'accès mémoire avec les anciens pointeurs après l'appel provoquera le rejet immédiat du programme avec l'erreur R1 invalid mem access. Le développeur doit obligatoirement recharger ctx->data et ctx->data_end, puis réitérer les tests de limites :

// 1. Ajuster l'espace en tête
if (bpf_xdp_adjust_head(ctx, 0 - (int)encap_size)) {
    return XDP_DROP;
}

// 2. RECHARGER IMMÉDIATEMENT LES POINTEURS
void *data = (void *)(long)ctx->data;
void *data_end = (void *)(long)ctx->data_end;

// 3. VÉRIFIER LES LIMITES AVANT TOUT ACCÈS
if (data + sizeof(struct ethhdr) + sizeof(struct iphdr) > data_end) {
    return XDP_DROP;
}

Implémentation complète : Encapsulation UDP au débit de ligne

Voici un programme eBPF en C complet et autonome démontrant l'encapsulation UDP zero-copy de flux IPv4 via bpf_xdp_adjust_head() :

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

#define TUNNEL_PORT 51820
#define ENCAP_SIZE (sizeof(struct ethhdr) + sizeof(struct iphdr) + sizeof(struct udphdr))

static __always_inline __u16 csum_fold_helper(__u32 csum) {
    csum = (csum >> 16) + (csum & 0xffff);
    csum += (csum >> 16);
    return (__u16)~csum;
}

SEC("xdp")
int xdp_vpn_encapsulate(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;

    // Contrôle de validité de l'en-tête Ethernet d'origine
    struct ethhdr *orig_eth = data;
    if ((void *)(orig_eth + 1) > data_end) {
        return XDP_PASS;
    }

    // Traitement exclusif des flux IPv4
    if (orig_eth->h_proto != bpf_htons(ETH_P_IP)) {
        return XDP_PASS;
    }

    // Agrandissement de l'en-tête de la taille requise
    if (bpf_xdp_adjust_head(ctx, 0 - (int)ENCAP_SIZE)) {
        return XDP_DROP;
    }

    // Réassignation des pointeurs après modification
    data = (void *)(long)ctx->data;
    data_end = (void *)(long)ctx->data_end;

    struct ethhdr *eth = data;
    struct iphdr *ip = (void *)(eth + 1);
    struct udphdr *udp = (void *)(ip + 1);

    if ((void *)(udp + 1) > data_end) {
        return XDP_DROP;
    }

    // Construction de l'en-tête Ethernet externe
    __builtin_memcpy(eth->h_dest, "\x52\x54\x00\x12\x34\x56", ETH_ALEN);
    __builtin_memcpy(eth->h_source, "\x52\x54\x00\xab\xcd\xef", ETH_ALEN);
    eth->h_proto = bpf_htons(ETH_P_IP);

    // Construction de l'en-tête IPv4 externe
    ip->version = 4;
    ip->ihl = 5;
    ip->tos = 0;
    ip->tot_len = bpf_htons((__u16)(data_end - (void *)ip));
    ip->id = 0;
    ip->frag_off = bpf_htons(IP_DF);
    ip->ttl = 64;
    ip->protocol = IPPROTO_UDP;
    ip->saddr = bpf_htonl(0x0a000001); // 10.0.0.1
    ip->daddr = bpf_htonl(0x0a000002); // 10.0.0.2
    ip->check = 0;

    // Calcul de la somme de contrôle IP
    __u32 csum = 0;
    __u16 *ip_words = (__u16 *)ip;
    #pragma unroll
    for (int i = 0; i < sizeof(struct iphdr) / 2; i++) {
        csum += ip_words[i];
    }
    ip->check = csum_fold_helper(csum);

    // Construction de l'en-tête UDP externe
    udp->source = bpf_htons(45000);
    udp->dest = bpf_htons(TUNNEL_PORT);
    udp->len = bpf_htons((__u16)(data_end - (void *)udp));
    udp->check = 0;

    // Émission directe du paquet encapsulé sur la ligne physique
    return XDP_TX;
}

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

Mesures de performances sur matériel dédié

Des tests de charge menés sur des adaptateurs réseau doubles 25 GbE Intel E810 avec des paquets de taille minimale (64 octets) mettent en évidence l'avantage de cette méthode :

Profil d'architecture Débit de transmission (Mpps) Latence moyenne ($\mu\text{s}$) Charge CPU mono-cœur (%)
Périphérique TUN standard + Espace utilisateur 1,8 Mpps 14,2 $\mu\text{s}$ 100 % (Goulot d'étranglement)
Module noyau conventionnel (VXLAN/UDP) 3,2 Mpps 8,6 $\mu\text{s}$ 100 % (Goulot d'étranglement)
Fastpath eBPF XDP (bpf_xdp_adjust_head) 14,6 Mpps 0,8 $\mu\text{s}$ 42 % (Débit de ligne matériel)

En s'affranchissant totalement de la structure sk_buff et en exploitant directement les descripteurs DMA, XDP multiplie le débit par 4,5 à 8 fois tout en réduisant la latence de transit de plus de 90 %.

Procédure d'exploitation et de vérification

La compilation et l'intégration du programme s'opèrent avec clang et les outils standard de la suite iproute2 :

# 1. Compiler le code source en bytecode BPF
clang -O2 -target bpf -c xdp_encap.c -o xdp_encap.o

# 2. Attacher le programme au hook natif du pilote sur eth0
ip link set dev eth0 xdpgeneric off
ip link set dev eth0 xdp obj xdp_encap.o sec xdp

# 3. Contrôler l'état de l'attachement XDP
ip link show dev eth0 | grep -i "xdp"

# 4. Consulter les statistiques d'exécution avec bpftool
bpftool prog dump xlated name xdp_vpn_encapsulate

Pour détacher proprement le programme :

ip link set dev eth0 xdp off

Déploiement au sein de l'architecture RiceGuard de VPNRice

Le réseau de transit Anycast mondial de VPNRice intègre pleinement l'accélération eBPF XDP :

  1. Inspection des flux en amont dans le pilote : À leur arrivée sur les nœuds de transit Anycast, les programmes XDP valident les identifiants cryptographiques directement en mémoire DMA, neutralisant les attaques par saturation avant même l'intervention du système d'exploitation.
  2. Encapsulation rapide inter-centres de données : Pour les liaisons de raccordement entre les routeurs centraux mondiaux, RiceGuard utilise bpf_xdp_adjust_head afin d'encapsuler le trafic chiffré au débit de ligne, évitant l'effet de bufferbloat et les contentions de verrous processeur.
  3. Bascule dynamique transparente : Dans les environnements virtualisés dépourvus de pilotes compatibles XDP natif, RiceGuard bascule automatiquement en mode générique (xdpgeneric), assurant une classification de paquets déterministe sur toute infrastructure.

La maîtrise de bpf_xdp_adjust_head ouvre la voie aux architectures réseau les plus performantes sous Linux, permettant une transformation des paquets à la vitesse physique du matériel.