Open Stack

Hi all,

da ich mit Bernd zusammen arbeite hier mal meine (versuchte) Antwort auf
die Fragen:

Am 23.03.2016 um 22:52 schrieb Sven Michels:
> [...]
> So wie Du das beschreibst, klingt es in erster Linie danach, als wuerde die
> Hashing Policy nicht greifen oder nicht sauber gesetzt sein. Vlt. kannst Du noch
> mal darauf achten, wie die Interfaceauslastung bei iperf wirklich ist? Also werden
> wirklich beide Links genutzt oder evtl. nur einer mit Kernel 4.1?
> Welche exakten Kernel Versionen werden denn genutzt? Ich erinner mich dunkel
> daran, das in dem Bereich einige Aenderungen am Kernel stattgefunden haben, die
> dafuer verantwortlich sein koennten.

Der Kernel der funktioniert: 3.16.0-67-generic #87~14.04.1-Ubuntu
Der Kernel der nicht so richtig wollte: 4.2.0-34.39~14.04.1

Bernds 4.1 war ein Missverständnis, es war eben 4.2

Eingehend hat übrigens auch der 4.2er Kernel funktioniert (sprich iperf
hin zum 4.2er Server hat 20 Gb ausgenutzt. Daher gehe ich auch davon
aus, dass es ein Problem mit dem Hashing bzw. der Hash Policy ist.

> Um das Problem ein bisschen einzugrenzen, sofern es Deine Zeit zulaesst, kann man
> folgende Punkte testen um vlt. ein paar Dinge auszuschliessen oder eben einen
> Ansatz zu finden wo man weiter suchen sollte:
> - ohne VLAN tagging testen
Hier bin ich aktuell nicht sicher, wie ich das ohne Downtime hinbekomme,
aber sobald mir etwas einfällt werd ich es versuchen ;)

> - Wie sehen die Offloading Settings der Karten aus?
Alles auf "default":
ethtool -k p2p1
Features for p2p1:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: on
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: on
        tx-checksum-fcoe-crc: on [fixed]
        tx-checksum-sctp: on
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-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: on [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off
busy-poll: on [fixed]

> - LACP nochmal verifizieren (bei 4.1 wurde port churn-maschine implementiert,
>   vlt. klemmts da)
Wie gesagt, eingehend tut es und auch ausgehend bekommt man mehr als 10
Gb, wenn man viele iperfs zu vielen Servern startet (ich habe 4 iperfs
mit je 4 Threads gestartet und bin dann auf knapp 20 Gb gekommen. Sofern
mich iperf nicht belügt und ich mich nicht verrechnet habe, sollte LACP
so grundsätzlich tun.

> - CPU Auslastung bei den Tests mit 3.16 vs. 4.1
> - Energiesparmodi im Bios etc. deaktivieren
Die beiden Punkte habe ich auf die Todo Liste geschrieben, sobald wir
wieder eine Downtime haben, werde ich das mal versuchen.

> Beim Offloading z.B. weiss ich, das mit den Intel Treibern + Bridge die Performace
> unterirdisch sein kann. IIRC war das beim Bonding genauso. TSO aus half (falls
> mich meine Erinnerung nicht verlassen hat).
> 
> Bzgl. Energiesparmodi: einige Server schalten nicht aus dem Energiesparmodus und
> versauen die Performance. Gerade bei "nur ein iperf" kommt das zum tragen. Daher
> zum Testen abschalten und gucken ob das was bewirkt.
> 
> Hoffe das hilft.
Vielen vielen Dank für den tollen Input, wir testen weiter und berichten.

MfG
-Sascha-