Sur cette page
À retenir
- Préciser la couche mesuréeOctets IP, trames Ethernet et occupation du lien donnent des valeurs en Gbit/s différentes.
- Examiner chaque file et chaque cœurUne faible moyenne CPU peut masquer une partie saturée du chemin de réception.
- Qualifier la politique réelleTransférer, rejeter, suivre des états et inspecter le trafic sont des charges différentes.
Les petits paquets peuvent révéler une autre limite
Un haut débit de paquets implique de nombreuses décisions de réception, d’analyse, de recherche et de transfert par seconde. Selon l’implémentation, certaines sont matérielles, d’autres consomment CPU, bande passante mémoire ou état partagé. Les petits paquets peuvent révéler une limite de traitement avant que le débit nominal du lien soit atteint.
Le symptôme seul n’identifie pas le composant limitant. Les pertes peuvent apparaître sur l’accès amont, une file de la carte réseau, un worker, l’allocation d’états ou le lien de sortie. Localisez la première étape défaillante avant de changer de matériel ou de framework de filtrage.
Relier les Mpps à une taille de trame explicite
Pour l’occupation Ethernet nominale dans un sens : Gbit/s = Mpps × (octets de trame + 20) × 8 / 1000. La trame comprend ici le FCS ; les 20 octets supplémentaires représentent le préambule et le temps intertrame. C’est un modèle de comptage, pas un benchmark de filtrage obtenu.
Une capture peut omettre le FCS et un compteur IP exclut la surcharge Ethernet. Indiquez ce que compte votre graphique avant de le comparer au modèle. Les exemples ci-dessous n’ajoutent pas de calcul PHY/FEC distinct et ne garantissent pas qu’une interface réelle soutienne le maximum théorique.
| Trame avec FCS | À 10 Mpps | Maximum nominal sur 100 Gbit/s |
|---|---|---|
| 64 octets | 6,72 Gbit/s | 148,81 Mpps |
| 128 octets | 11,84 Gbit/s | 84,46 Mpps |
| 512 octets | 42,56 Gbit/s | 23,50 Mpps |
| 1518 octets | 123,04 Gbit/s | 8,13 Mpps |
Réduire le travail avant l’étape saturée
Si la bande passante amont est épuisée, déplacez la réduction en amont ou modifiez la livraison. Si le traitement local est la limite mesurée, examinez le filtrage précoce pris en charge, les files, le placement des workers et le coût des règles prévues. Un rejet tardif n’annule pas le travail déjà effectué.
XDP, une application DPDK, VPP et une ACL d’équipement sont des environnements d’exécution différents, pas un classement universel des performances. Comparez la politique requise sur le matériel réel. Documentez les analyses prises en charge, les états, les mises à jour et le comportement si une fonction manque ou si un processus s’arrête.
Mesurer la répartition, pas seulement les totaux
Le RSS répartit généralement les paquets entre les files selon un hachage de champs d’en-tête. De nombreux flux peuvent bien se répartir, tandis qu’un autre mélange concentre le travail. Une file ou un worker surchargé peut perdre des paquets alors que la moyenne CPU reste faible. Vérifiez la correspondance réelle et les compteurs par file au lieu de supposer que davantage de cœurs suffisent.
Incluez la localité NUMA, l’emplacement de la carte réseau, la capacité PCIe, l’affinité des workers et les files d’émission dans le relevé. Leur effet dépend de la plateforme et de l’implémentation. Ne copiez pas une recette de réglage sans mesurer le chemin existant et conserver une configuration réversible.
Exemple : « 100 Mpps » exige un contexte précis
Avec des trames Ethernet de 64 octets, 100 Mpps représentent 67,2 Gbit/s d’occupation nominale. À 1518 octets, ce même débit de paquets représente 1230,4 Gbit/s. Une annonce de « 100 Mpps » sans taille de trame, sens ni charge de travail est donc incomplète.
Pour un déploiement hypothétique à deux nœuds, ne divisez pas simplement la charge proposée par deux. Testez l’orientation du trafic et une répartition inégale, puis la panne que le service doit tolérer. Si tout le trafic protégé peut rejoindre un seul nœud survivant, celui-ci et ses liens récepteurs demandent une capacité qualifiée séparément.
Construire un relevé de capacité reproductible
Décrire le système
Notez carte réseau, firmware, pilote, CPU, mémoire, topologie NUMA, versions logicielles, ports et fonctions actives. Précisez si les résultats concernent un sens ou un agrégat.
Décrire le trafic
Notez tailles, protocoles, nombre de flux, création d’états, proportion de trafic légitime et indésirable et durée. Utilisez un environnement isolé autorisé avec des mesures synchronisées.
Mesurer le transfert utile
Recueillez les paquets proposés, rejetés et transmis à des points nommés. Mesurez aussi les transactions légitimes réussies, la latence et les pertes ; un rejet rapide seul n’est pas un résultat de transfert avec état.
Déterminer et vérifier la marge d’exploitation
Testez la charge prévue, les changements maîtrisés et la panne spécifiée. Gardez l’enveloppe de production sous la limite démontrée et documentez la marge choisie.
Lire les graphiques dans leur contexte d’exploitation
- N’additionnez pas réception et émission pour présenter le résultat comme une capacité entrante dans un seul sens.
- Ne déduisez pas la seconde la plus chargée d’une moyenne de cinq minutes ou d’un percentile de facturation.
- Ne supposez pas qu’un échantillonnage de flux voit chaque pic court ou fournit le même compteur que la carte réseau.
- N’appelez pas les paquets rejetés « trafic propre traité » sans préciser le traitement effectué.
- Un test réussi avec de grandes trames ne prouve pas la capacité en trames minimales.
Transformer le benchmark en décision de dimensionnement
Séparez limites théoriques du lien, capacité mesurée du traitement et résultats applicatifs. Lorsqu’une mesure manque, laissez-la inconnue. Un calculateur vérifie l’arithmétique et les contraintes des liens ; seul un test pertinent qualifie le système de filtrage.
Questions et réponses
Un débit élevé en Gbit/s suffit-il à dimensionner un filtre ?
Non. Taille et débit des paquets, politique, création d’états et répartition influencent la charge. Mesurez la configuration qui fonctionnera réellement.
Une faible charge CPU totale signifie-t-elle qu’il reste de la marge ?
Pas nécessairement. Une file, un worker, le chemin mémoire ou un lien externe peuvent limiter le système pendant que d’autres cœurs restent inactifs.
Peut-on vendre le débit Ethernet théorique comme capacité de filtrage ?
Non. C’est une limite d’occupation du lien sous des hypothèses précises. Une capacité produit exige des mesures sur le trafic et les fonctions concernés.
