BCM57416 auf ASRock Romed8-2T/BCM - SRIOV nicht unterstützt ?

[firefox_i 0]

Hallo zusammen,

ich bin gerade etwas am verzweifeln offen gesagt.

 

Folgendes Blech:

- ASRock Romed8-2t/BCM

- darauf ein Broadcom BCM57416 10Gbit Eth Dual Controller

- EPYC7282

- WIndows 2019, aktuellster Patchstand

 

 

Ich hab im BIOS SRIOV aktiviert, ebenfalls die virtualisierung der CPU, IOMMU und PCIe ARI.

 

Im Treiber des Netzwerkchips ist SRIOV ebenfalls Enabled.

 

Und dennoch:

 

PS C:\Users\Administrator> Get-NetAdapterSriov


Name                 : Ethernet 2
InterfaceDescription : Broadcom NetXtreme E-Series Dual-port 10GBASE-T Ethernet OCP 3.0 Adapter #2
Enabled              : True
SriovSupport         : NotSupported
SwitchName           : Default Switch
NumVFs               : 128

Name                 : Ethernet
InterfaceDescription : Broadcom NetXtreme E-Series Dual-port 10GBASE-T Ethernet OCP 3.0 Adapter
Enabled              : True
SriovSupport         : NotSupported
SwitchName           : Default Switch
NumVFs               : 128

 

 

Irgendwo hab ich nen Denkfehler, oder was mach ich falsch?

 

Wäre für jede Hilfestellung dankbar.

S.

[Nobbyaushb 1.359]

Moin,

hast du denn Perfomance-Probleme?

 

ASrock ist ja nun auch nicht das Serverboard…

Was für ein Switch hängt dahinter?

Hatte mit Broadcom in der Vergangenheit viel Probleme…

[testperson 1.534]

Hi,

 

fangen wir ggfs. einen Schritt vorher an: Warum SR-IOV? Was hast du denn später vor?

 

Gruß

Jan

[NorbertFe 1.805]

Ist das ein set Switch? Dann kann der kein sr-iov afair.

bearbeitet 22. März 2023 von NorbertFe

[firefox_i 0]

Danke schonmal,

vor 32 Minuten schrieb NorbertFe:

Ist das ein set Switch? Dann kann der kein sr-iov afair.

Was meinst du mit "Ist das ein Switch"?
Mit dem cmdlet komm ich an die EIgenschaften der Netzwerkkarte.

Ich versteh die Frage nicht ganz.

Also....dahinter hängt ein Netgear 10GBit Switch.

 

netio ergibt folgendes:
 

TCP connection established.
Packet size  1k bytes:  106.87 MByte/s Tx,  626.73 MByte/s Rx.
Packet size  2k bytes:  152.76 MByte/s Tx,  722.10 MByte/s Rx.
Packet size  4k bytes:  271.76 MByte/s Tx,  683.71 MByte/s Rx.
Packet size  8k bytes:  460.41 MByte/s Tx,  596.64 MByte/s Rx.
Packet size 16k bytes:  492.55 MByte/s Tx,  582.18 MByte/s Rx.
Packet size 32k bytes:  595.75 MByte/s Tx,  593.70 MByte/s Rx.
Done.

 

Ein Core geht dabei nahezu auf Anschlag.

 

Ich hätt ejetzt ein wenig mehr erwartet und deshalb den Ansatz mit SR-IOV mehr rauszuholen.

Auf dem HyperV werden nachher folgende virtuelle Maschinen gehostet:

- DC

- 2 Filserver

- 1 RDS Server für ca 10 Anwender

 

Wenn die Meinung vorherrst, dass SR-IOV da sinnlos ist okay, dann nehm ich das als Anregung, denn offen gesagt habe ich mit SR-IOV noch wenig Erfahrungen.

MIch hat eben gewundert, dass die Karte - obwohl sie es eigentlich kann - nicht supported laut dem cmdlet

S-

[testperson 1.534]

vor einer Stunde schrieb firefox_i:

Wenn die Meinung vorherrst, dass SR-IOV da sinnlos ist okay, dann nehm ich das als Anregung, denn offen gesagt habe ich mit SR-IOV noch wenig Erfahrungen.

...

Auf dem HyperV werden nachher folgende virtuelle Maschinen gehostet:

- DC

- 2 Filserver

- 1 RDS Server für ca 10 Anwender

Das ist (an dieser Stelle) sinnlos.

 

[NorbertFe 1.805]

vor 8 Stunden schrieb firefox_i:

Was meinst du mit "Ist das ein Switch"?

 

vor 8 Stunden schrieb firefox_i:

Ist das ein set Switch?

SET switch embedded teaming.

[firefox_i 0]

vor 38 Minuten schrieb NorbertFe:

 

SET switch embedded teaming.

Ah okay,
Sorry hab ich vergessen zu sagen:
Ich hab nur eine Leitung zum Switch, der zweite Port im Server ist sogar deaktiviert. 
Also langer Rede kurzer SInn: KEIN Teaming. 

Daran kann es also leider nicht liegen, aber danke für den Hinweis.
Dachte zwar gelesen zu haben, dass auch bei einer geteamten Anbindung SR-IOV umsetzbar ist, aber das isthier ja erst mal irrelevant.

S.

[NorbertFe 1.805]

vor 11 Minuten schrieb firefox_i:

Dachte zwar gelesen zu haben, dass auch bei einer geteamten Anbindung SR-IOV

Eine geteamte Verbindung und set sind ja auch nicht gleichzusetzen. ;)

[firefox_i 0]

vor 7 Stunden schrieb testperson:

Das ist (an dieser Stelle) sinnlos.

 

Hey, danke für die Einschätzung.

Kannst es mir in wenigen Worten erklären warum?
Mein Verständnis war, dass sich der Hypervisor bei SR-IOV nicht drum lümmern muss, sondern dass das die einzelnen Gastsysteme machen.

Oder ist hier einfach zu wenig Workload da?

 

Ich hab eben die Beobachtung gemacht, wenn ich aus dem Host raus Daten an ein NAS schicke (auch 10G angebunden, das mit dem ich die netio Messung gemacht habe) ich eben nie über 4GBit komme. Und im Ressourcenmonitor "pumpt" die Datenrate....geht hoch, dann wieder kurz auf 0, dann wieder hoch...wenn weißt was ich mein.

Apropos Workload:
Wie ist denn die Philosophi ehier mit Virtualisierung auf der physikalischen CPU?
Seit Server2019 ist ja der CoreScheduler Default und der packt mir Threads verschiedener VMs ja nicht mehr auf eine pCPU.
Und da sind die einen Verfechtechter von "lass es an, der Hypervisor nutzt das schon aus" und die anderen sagen "ausmachen, dann hast mehr Performance, weil keine Workload auf den virtuellen Kernen läuft."

S.

vor 1 Minute schrieb NorbertFe:

Eine geteamte Verbindung und set sind ja auch nicht gleichzusetzen. ;)

Ich weiß
ABer wie gesagt: weder das eine, noch das andere existiert und kann daran schuld sein, dass die Karte da ein "NotSupported" meldet....

S:

[NilsK 2.785]

Moin,

 

es scheint mir ein Missverständnis vorzuliegen, was SR-IOV überhaupt ist. Das ist kein Performancebooster für "die" Netzwerkkarte. Es ist eine Technik, um eine einzelne Hardware-Karte in mehrere virtuelle Karten aufzuteilen.

 

https://learn.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-single-root-i-o-virtualization--sr-iov-

 

Das erzeugt eine recht hohe Komplexität und ist deshalb nur in wenigen Szenarien sinnvoll. Der von dir angeführte Workload gehört nicht dazu, das ist doch sehr überschaubar. Das bekommt man mit normalen Mitteln besser und einfacher in den Griff.

 

Gruß, Nils

PS. ich ergänze noch: warum du die Funktion anscheinend nicht aktiviert bekommst, ist etwas rätselhaft. Wie @Nobbyaushb schon andeutet, können das durchaus Fehler in den Treibern sein. Da die Technik in der Praxis sehr selten verwendet wird, kann es dabei sein, dass die Fehler "nicht wichtig genug" sind ... das ist aus unserer Sicht aber auch egal, denn unsere Empfehlung ist, das einfach wegzulassen.

 

 

bearbeitet 23. März 2023 von NilsK

[zahni 521]

Ich zitiere mal:

 

Zitat

SR-IOV-Funktionalität ist gegenwärtig nur auf Windows 8- und Windows Server 2012-Gastsystemen verfügbar.
Hyper-V muss auf einem Windows Server 2012 (oder neuer) ausgeführt werden.
Sie benötigen einen SR-IOV-kompatiblen physischen Netzwerkadapter mit PF-Unterstützung, der VF-Anfragen der VMs umsetzen kann.
Sie benötigen einen externen virtuellen Switch, der SR-IOV-Traffic beherrscht.
Auch der Chipsatz der Hauptplatine Ihres Servers muss SR-IOV unterstützen.

https://www.computerweekly.com/de/antwort/Was-ist-Single-Root-I-O-Virtualisierung-SR-IOV-und-welchen-Vorteil-bringt-sie

 

Das Board muss die Option im BIOS aktiviert haben und der Switch muss es auch können.

[NilsK 2.785]

Moin,

 

vor 6 Minuten schrieb zahni:

Sie benötigen einen externen virtuellen Switch, der SR-IOV-Traffic beherrscht.

das ist Unsinn. Ein "externer virtueller Switch" ist ein Objekt in Hyper-V. Der kann gar keinen solchen Traffic beherrschen, der weiß nichts davon. Der Witz an SR-IOV ist ja gerade, dass der VM-Traffic am Hypervisor vorbeigeht.

 

Der Artikel ist noch aus einer Zeit, als die Technik nagelneu war, da hat man sich als Autor aus den verfügbaren Quellen was zusammengereimt. Testen konnte man es damals praktisch noch nicht. Auch in "dem Buch" hatten wir das Problem, aber Jan hat seinerzeit deutlich besser recherchiert als der CW-Autor. 

 

Nach meiner Kenntnis ist der physische Switch bei SR-IOV nicht beteiligt. Ist aber, wie gesagt, auch egal. Erstens funktioniert es hier ohnehin nicht und zweitens ist es unnötig.

 

Gruß, Nils

 

[firefox_i 0]

Hallo zusammen,

danke für die ganzen Infos.

Aus diversen Quellen entstand für mich eben der Eindruck, dass SR-IOV das Thema mit dem "pumpenden" Traffic lindert.
Dass es kein Booster ist war mir klar. 
Auch was man dafür auf BIOS Seite aktiviert haben muss (hatte ich ja eingangs auch beschrieben).

Aber wenn das eh selten verwendet wird und hier eh nix bringt, dann ist das ja jetzt auch eine Erkenntnis.

Dann erstell ich lediglich den vSwitch nochmal neu, denn da hab ich bei der Erstellung "SR-IOV ja bitte" gesagt.

Danke nochmal für eure Hilfe.

S.

[NilsK 2.785]

Moin,

 

allgemein solltest du in der Virtualisierung keine "einfachen" Performancetests durchführen. Die meisten davon geben keine zutreffenden Ergebnisse aus, weil sie nicht an den Stellen messen, die bei der Virtualisierung relevant sind.

 

Bei den beschriebenen Workloads wirst du die 4 Gbit/s, die ohne weitere Optimierung von einer 10-GbE-Karte zu erwarten sind, ohnehin nicht auslasten. Und selbst wenn - dann dauert es halt eine Sekunde länger, eine riesige Datei zu kopieren. Ich würde da noch nicht mal in Erwägung ziehen, eine der erweiterten Techniken zu nutzen, ob es nun SR-IOV ist oder VMQ oder was auch immer. 

 

Gruß, Nils