effectivement si ca n'apporte rien autant ne pas l'activer...

mais 2 points:

ton "lan" est un bridge on dirait dans ce cas il faut ajouter les interfaces physiques  dans ta flowtable ( https://docs.kernel.org/networking/nf_flowtable.html#bridge-and-ip-forwarding )

If you would like that your flowtable defines a fastpath between your bridge ports and your IP forwarding path, you have to add your bridge ports (as represented by the real netdevice) to your flowtable definition.

as tu essayer d'activer l'offload hardware ? (flags offload : https://docs.kernel.org/networking/nf_flowtable.html#hardware-offload )

J'ai relancé le même script qu'hier : 4 iperf avec offload puis 4 sans offload. En mettant l'offload sur les interfaces physiques, on voit déjà que le compteur de bytes de wan0 n'augmente plus, c'est marrant

Par contre, toujours autant de dropped avec offload, presque même plus que sans. C'est fou, est-ce j'interprète mal les métriques ? On dirait que même le débit est meilleur sans offload qu'avec.

pour les compteurs c'est dans la doc: https://docs.kernel.org/networking/nf_flowtable.html#counters

Ça ne change rien aux compteurs rx/tx bytes de l'interface VLAN mais de toute façon ce n'est pas un problème, ça permet au moins de voir que l'offload fonctionne.

As tu essayé sans bridge ? (pourquoi as tu besoin d'un bridge ?)

J'ai un LAN en 2.5G avec du PoE et un serveur en 10G. Trouver un switch avec à la fois 2 ports 10G et du PoE en 2.5G me semblait compliqué et très cher, c'était l'une des raisons de l'achat du routeur : mettre le LAN en 2.5G sur un des ports 2.5G du bridge et le serveur en 10G sur le port 10G du bridge. Je pense que, si la box avait eu des ports 2.5G comme la Freebox Ultra, je n'aurais jamais réfléchi à la remplacer

Je n'ai pas essayé sans le bridge, tu crois vraiment que ça joue ? Les compteurs de bytes du bridge LAN ne bougent pas quand l'offload est actif, même principe que le VLAN du WAN. Ça serait un peu compliqué de tester sans et je ne suis pas sûr que ça vaille la peine car l'offload semble déjà faire son travail.

les buffers sont-ils bien réglés ?

notamment:

Code: [Sélectionner]

sudo sysctl net.core  | grep mem_max


Je n'ai pas du tout touché aux sysctl, peut-être qu'il y a des choses à améliorer ici, en effet :
net.core.optmem_max = 131072
net.core.rmem_max = 212992
net.core.wmem_max = 212992
Tu as une doc en tête pour optimiser ça au mieux ?

sinon regardes les stats des interfaces (y'a les méthodes ici: https://docs.kernel.org/networking/statistics.html)

Je vais lire ça, merci.

est-ce pareil en ipv6/ipv4 ? (le NAT n'est pas offload , c'est que le forwarding donc un flux IPv4 reste peut-etre "cpu bound" a cause du NAT meme si le forwarding va plus vite).

Je n'ai toujours pas testé en IPv6, je te dirai quand ça sera fait

ah bien pour le NAT je n'avais pas vu ce point. dommage pour IPv6.

sinon c'est peut-etre un souci/bug de ta version du kernel ? uname -a ca donne quoi ? (apres j'en doute un peu, flowtable n'est pas si récent que cela).

éventuellement faire un dual boot sur ton R2 pour tester d'autre distro / réglages ?

pour les opti sysctl je n'ai pas grand chose pour un linux qui fait "routeur". il faut chercher y'a sans doute des infos quelque part  (regarde peut-etre les valeurs par défaut dans openwrt par exemple?).

Les valeurs par défaut d'OpenWRT sont clairement bien pour du gigabit mais insuffisantes pour du 10G.

Code: [Sélectionner]

net.core.rmem_default = 212992
net.core.rmem_max = 212992
net.core.rps_sock_flow_entries = 0
net.core.somaxconn = 4096
net.core.tstamp_allow_data = 1
net.core.warnings = 0
net.core.wmem_default = 212992
net.core.wmem_max = 212992
A minima, il faudra augmenter les valeurs rmem et wmem sans compter sur les options de la carte réseau.

On trouve des ressources utiles, par exemple:
https://fasterdata.es.net/host-tuning/linux/
https://cdrdv2.intel.com/v1/dl/getcontent/334019
https://people.ucsc.edu/~warner/buffer.html
https://wiki.archlinux.org/title/Sysctl#Improving_performance

les réglages pour un serveur ou un client (qui terminent/commencent une connexion tcp ou udp via un socket(2)) et pour un routeur(qui n'est que traversé par la connexion) ne sont pas forcement les mêmes.

je ne suis pas sur que rmem et wmem influent autant sur un routeur (chaine forward surtout avec le fastpath, rien en userspace) comme sur un serveur/poste (chaines input et output et un utilisation socket en userspace donc utilisation des valeurs net.core.. et)

a mon avis c'est plus coté option carte réseau que ca doit jouer.

a creuser. c'est ce qu'on cherche.

Est-ce que t'as regardé si la carte Marvell utilisait bien toute sa bande passante pci ? Le souci du N100 c'est qu'il n'a que 9 ligne pci gen3 en tout donc selon les cas les fabricants de mini pc doivent parfois sacrifier les perfs ... que dit lspci -vvv sur le nombre de ligne PCI et la vitesse total allouée à la carte réseau marvel ?

Les tests que j'avais lus indiquaient bien que ce n'était pas un problème. Je viens de vérifier :
$ lspci -nnvvs 07:00.0
07:00.0 Ethernet controller [0200]: Aquantia Corp. AQC113C NBase-T/IEEE 802.3an Ethernet Controller [Marvell Scalable mGig] [1d6a:14c0] (rev 03)
  Subsystem: Aquantia Corp. Device [1d6a:0001]
[…]
    LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM not supported
      ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
    LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
      ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
    LnkSta: Speed 8GT/s, Width x2
      TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
En PCIe Gen 3, x2 nous donne 1.969 GB/s donc > 10 Gb/s sans problème.

Aussi vu que tu n'as que 4 coeurs est-ce que les interruptions sont bien répartis entre les coeur ? (cat /proc/interrupts)

J'ai l'impression que sur une seule connexion TCP, ça n'est pas le cas, je n'ai que 2 compteurs sur 4 qui augmentent fortement.
Every 0.1s: grep lan0 /proc/interrupts                                                                                                                                             router: Sun Mar 16 14:34:2[0/31]
                                                                                                         
 134:  365285436          0          0          0  IR-PCI-MSIX-0000:07:00.0    0-edge      lan0
 135:          0   50637034          0          0  IR-PCI-MSIX-0000:07:00.0    1-edge      lan0
 136:          0          0  419998770          0  IR-PCI-MSIX-0000:07:00.0    2-edge      lan0
 137:          0          0          0   10079144  IR-PCI-MSIX-0000:07:00.0    3-edge      lan0
 138:          0          0          0          0  IR-PCI-MSIX-0000:07:00.0    4-edge      lan0
Si je mets 8 connexions TCP par contre, les 4 compteurs augmentent bien simultanément. Le dernier reste à 0, je ne sais pas ce qu'il représente.
En tout cas, ça confirme ce que je vois sur les graphes de CPU : seuls 1 ou 2 cœurs prennent le trafic quand je suis en mono-connexion.

Il faudrait aussi que je m'amuse à grapher les inpackets/outpackets des 4 queues de chaque NIC :
Every 0.1s: ethtool -S lan0 | grep -Pi '(inpackets|outpackets):'                                                                                                                   router: Sun Mar 16 14:38:1[0/35]
                                                                                                         
     InPackets: 3266062976                                                                               
     OutPackets: 1316155604                                                                             
     Queue[0] InPackets: 21093433                                                                       
     Queue[0] OutPackets: 1127948050                                                                     
     Queue[1] InPackets: 181200073                                                                       
     Queue[1] OutPackets: 83390005                                                                       
     Queue[2] InPackets: 3016562247                                                                     
     Queue[2] OutPackets: 11937344                                                                       
     Queue[3] InPackets: 47249083                                                                       
     Queue[3] OutPackets: 11259373                                                                       
Il me semble que ce sont parfois des queues différentes qui prennent les paquets en entrée et en sortie (par exemple Queue[3] InPackets semble augmenter proportionnellement à Queue[0] OutPackets), mais il me faudra un graphique pour mieux visualiser.

Ma dernière piste pour gagner en performance serait d'utiliser la flowtable avec XDP (xdp-forward). Mais pour ça, il faut patcher le kernel car les VLAN ne sont pas supportés pour le moment : https://github.com/xdp-project/xdp-tools/issues/488.