Auteur Sujet: Comment monter un réseau 10Gbit/s chez soi (Lu 1128943 fois)

hwti · « **Réponse #300 le:** 03 janvier 2019 à 05:02:13 »

Citation de: Nh3xus le 03 janvier 2019 à 02:38:52

J'ai quelques questions du coup :

- Quels sont les CPU de tes deux machines ?
- Est-ce que ces cartes font de l'offload pour les flux TCP ?
- Quid des perf sous Windows ? (oui je sais...)

Pour l'instant les deux cartes sont sur une unique machine, avec un Threadripper 1950X (le test est avec un serveur et un client iperf lancé dans deux namespaces avec chacun une carte attachée).
Je ferai des tests avec ma machine Windows qui est plus ancienne (i7-3930K overclocké) quand j'aurai un peu de temps.
Dans les deux cas, il s'agit bien de ports PCIe 8x/16x reliés directement au CPU, donc la carte n'est pas bridée de ce côté là (PCIe 2.0 8x).

Côté accélération, il manque le LRO (large receive offload), le driver implèmente le GRO (generic receive offload) mais pas HW.
EDIT : le driver de Mellanox (qui ne supporte plus la ConnectX-2, du moins officiellement) a du code LRO, mais c'est un LRO software qui a été remplacé par le GRO software dans le kernel en 2011). Pour ce qui est des cartes Mellanox sous Linux, seul le driver mlx5 (ConnectX-4) supporte le LRO HW, pas mlx4 (ConnectX/X-2/X-3).
Sinon il y a bien sûr les checksums IPv4/v6 TX/RX, et le TSO (TCP segmentation offload) pour les envois.

Code: [Sélectionner]

rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: on
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: on
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: on
rx-vlan-stag-filter: on [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: on
tls-hw-tx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]

Johannol · « **Réponse #301 le:** 03 janvier 2019 à 08:01:41 »

hwti: Merci beaucoup. Du coup, j'ai aussi mes questions:

Pour faire un test avec 2 cartes dans le même PC, tu as suivi une procédure/tuto disponible quelque part?

Sinon j'ai une autre question: la carte Mellanox est-telle utilisable "out of box" dans un linux avec les drivers du Kernel? ou alors est-ce qu'on se retrouve obligatoirement avec un driver à recompiler à chaque mise à jours du kernel?

Merci

Johannol · « **Réponse #302 le:** 03 janvier 2019 à 08:08:10 »

Citation de: docmarc le 31 décembre 2018 à 17:02:17

un tuto claire et bien fait sur le câblage des noyaux RJ45

Merci pour le tuto ( et l'explicatif des cartes Intel ! ) J'ai de quoi m'inspirer pour mon prochain cablage.

hwti · « **Réponse #303 le:** 03 janvier 2019 à 09:11:00 »

Citation de: Johannol le 03 janvier 2019 à 08:01:41

hwti: Merci beaucoup. Du coup, j'ai aussi mes questions:

Pour faire un test avec 2 cartes dans le même PC, tu as suivi une procédure/tuto disponible quelque part?

J'ai trouvé la suggestion d'utiliser les namespaces sur stackoverflow (ce qui est bien plus simple que les solutions à base de règles iptables), j'ai ensuite fait moi-même.
Je n'ai pas vérifié si un seul namespace n'était pas suffisant, mais en utiliser deux permet de partir sur des règles iptables vides et donc potentiellement limiter la charge CPU :

Code: [Sélectionner]

# ip netns add server
# ip link set dev enp10s0 netns server
# ip netns exec server ip link set enp10s0 up
# ip netns exec server ip addr add 192.168.2.1/24 dev enp10s0
# ip netns exec server iperf3 -s

# ip netns add client
# ip link set dev enp66s0 netns client
# ip netns exec client ip link set enp66s0 up
# ip netns exec client ip addr add 192.168.2.2/24 dev enp66s0
# ip netns exec client iperf3 -c 192.168.2.1 -t 20

Bien sûr pour tester deux cartes dans le même PC il faut avoir deux ports PCIe 8x de libres, ce qui n'est pas le cas de la majorité des PC (à moins de ne pas installer de carte graphique).

Citation de: Johannol le 03 janvier 2019 à 08:01:41

Sinon j'ai une autre question: la carte Mellanox est-telle utilisable "out of box" dans un linux avec les drivers du Kernel? ou alors est-ce qu'on se retrouve obligatoirement avec un driver à recompiler à chaque mise à jours du kernel?

Le driver mlx4 est intégré au kernel, il n'y a donc rien à faire, la carte fonctionne immédiatement.

Thornhill · « **Réponse #304 le:** 03 janvier 2019 à 10:35:23 »

Citation de: hwti le 03 janvier 2019 à 09:11:00

Je n'ai pas vérifié si un seul namespace n'était pas suffisant, mais en utiliser deux permet de partir sur des règles iptables vides et donc potentiellement limiter la charge CPU :

Je suppose qu'à défaut de namespace séparé, le client et le serveur iperf3 communiqueraient uniquement en SW à travers le kernel (sans passer par les cartes HW) car les 2 @IP seraient locales ?

Johannol · « **Réponse #305 le:** 03 janvier 2019 à 10:42:37 »

Citation de: hwti le 03 janvier 2019 à 09:11:00

J'ai trouvé la suggestion d'utiliser les namespaces sur stackoverflow (ce qui est bien plus simple que les solutions à base de règles iptables), j'ai ensuite fait moi-même.

Excellent! Avec une paire d'adaptateur RJ45 https://www.eurodk.com/en/products/fiber-modules-mikrotik/sfp-s-plus-rj10-module dont j'ai vu qu'ils étaient compatible Mellanox 2 (à 9.3Gb/s), et une paire de carte, j'ai moyen de tester l'ensemble du câblage optique et RJ45 que j'envisage de faire, et au passage valider les choix de noyaux et de prises murales Legrand avant d'y passer trop de temps et d'argent.

Merci aussi pour la conf!!

Je pourrais aussi répondre à la question de Nh3xus

Citation de: Nh3xus le 01 janvier 2019 à 01:06:56

Perso, je suis curieux de voir les perfs d'un réseau 10Gbits/s @home non certifié au Fluke.

Et voir à combien va un réseau cablé qui "tombe en marche" par un débutant qui suit les conseils données sur lafibre.info

Citation de: hwti le 03 janvier 2019 à 09:11:00

Bien sûr pour tester deux cartes dans le même PC il faut avoir deux ports PCIe 8x de libres, ce qui n'est pas le cas de la majorité des PC (à moins de ne pas installer de carte graphique).

J'ai 2 x16 de libre sur ma Gigabyte Z370M D3H dont je n'utilise que la sortie 4K sur DisplayPort lié au GPU Intel (j'avais pris cette carte pour cela). Check.

Citation de: hwti le 03 janvier 2019 à 09:11:00

Le driver mlx4 est intégré au kernel, il n'y a donc rien à faire, la carte fonctionne immédiatement.

Nickel, double carte commandé. Un gros merci à toi!

Au pire j'en revendrai une, une fois l'installation "auto-certifié"... et encore c'est pas gagné vu qu'il y en a qui l'ont fait marcher dans des NAS Synology...

hwti · « **Réponse #306 le:** 03 janvier 2019 à 11:16:40 »

Citation de: Thornhill le 03 janvier 2019 à 10:35:23

Je suppose qu'à défaut de namespace séparé, le client et le serveur iperf3 communiqueraient uniquement en SW à travers le kernel (sans passer par les cartes HW) car les 2 @IP seraient locales ?

Sans aucun namespace, les deux IP sont locales, donc effectivement le client et le serveur communiqueraient via loopback.
D'après ce que j'ai lu, même en assignant les processus à une interface (ce serait l'option -B de iperf3) et en supprimant les routes, il y aurait des problèmes avec l'ARP.

hwti · « **Réponse #307 le:** 03 janvier 2019 à 11:33:21 »

Citation de: Johannol le 03 janvier 2019 à 10:42:37

J'ai 2 x16 de libre sur ma Gigabyte Z370M D3H dont je n'utilise que la sortie 4K sur DisplayPort lié au GPU Intel (j'avais pris cette carte pour cela). Check.

https://www.gigabyte.com/fr/Motherboard/Z370M-D3H-rev-10#sp

Citer

1 x PCI Express x16 slot, running at x16 (PCIEX16)
1 x PCI Express x16 slot, running at x4 (PCIEX4)

Certaines cartes Z370 doivent permettre d'avoir deux ports PCIe issus du CPU en x8, mais ici ce n'est pas le cas.
Donc la 2ème carte serait en x4 (le débit théorique, 16Gb/s, est suffisant, à voir quand même), et sur le chipset (relié par l'équivalent d'un PCIe 3.0 4x au CPU).

docmarc · « **Réponse #308 le:** 03 janvier 2019 à 14:17:52 »

je suis en train de faire un tableau de compatibilités OS des cartes réseaux cité

Si quelqu’un a une x7xx peut t'il me confirmer que cette série n'est pas supporter par Windows 7,8,8.1,10 ?

selon le tableau intel du 14/12/2018 c'est Non

Tableaux des compatibilités OS sur les différentes cartes réseaux INTEL

Johannol · « **Réponse #309 le:** 03 janvier 2019 à 14:30:46 »

Citation de: hwti le 03 janvier 2019 à 11:33:21

https://www.gigabyte.com/fr/Motherboard/Z370M-D3H-rev-10#sp
Certaines cartes Z370 doivent permettre d'avoir deux ports PCIe issus du CPU en x8, mais ici ce n'est pas le cas.
Donc la 2ème carte serait en x4 (le débit théorique, 16Gb/s, est suffisant, à voir quand même), et sur le chipset (relié par l'équivalent d'un PCIe 3.0 4x au CPU).

Damned

Mais merci à toi, si je n’atteins pas 9.4Gbit en Direct Attach entre les 2 cartes, je saurais pourquoi... ainsi peut-être que ton CPU 119% plus performant que le mien (Intel i5-8400)

Je ne vais pas me casser la tête, même si cela plafonne un peu plus bas, avec le Direct Attach j'aurai normalement une référence correcte qui suffira pour tester le bon câblage du RJ45 / Optique, ainsi que la qualité des prises murale Legrand.

BadMax · « **Réponse #310 le:** 03 janvier 2019 à 15:35:00 »

Sous Linux, si vous voulez vérifier si la vitesse d'un port PCIe est bonne:

Code: [Sélectionner]

lspci -vv
Et, pour chaque device PCIe, vérifier les lignes sous "Capabilities: [xx] Express (vY) Endpoint" (avec éventuellement Legacy):
- LnkCap: capacité de la carte
- LnkSta:lien négotié avec la CM

Quelques exemples:
- carte RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
LnkCap: Port #0, Speed 2.5GT/s, Width x1
LnkSta: Speed 2.5GT/s, Width x1
=> pas de problème, on a 250MB/s
- contrôleur RAID Marvell 88SE6440
LnkCap: Port #0, Speed 2.5GT/s, Width x4
LnkSta: Speed 2.5GT/s, Width x1
=> le contrôleur est prévu pour 4x lignes soit 1000MB/s alors qu'il n'a qu'une ligne connectée soit 250MB/s -> ça peut coincer
- GTX 1070
LnkCap: Port #0, Speed 5GT/s, Width x16
LnkSta: Speed 2.5GT/s, Width x16
=> bien que la CM supporte PCIe 2.0 (5GT/s), la GTX est en PCIe 1.0 (2.5GT/s).

Dans le cas d'une carte 10Gb, 5GT/s (PCIe 2.0) en x4 me parait le minimum (4x 500MB) même si ça peut encore passer en x2 ou 2.5GT x4.

hwti · « **Réponse #311 le:** 03 janvier 2019 à 19:09:00 »

Citation de: BadMax le 03 janvier 2019 à 15:35:00

Dans le cas d'une carte 10Gb, 5GT/s (PCIe 2.0) en x4 me parait le minimum (4x 500MB) même si ça peut encore passer en x2 ou 2.5GT x4.

5GT x2 ou 2.5GT x4 ça fait seulement 8Gbps théoriques à cause de l'encodage 8b10b (PCIe 1.x/2.0), donc ça briderait pas mal.