Werden Pause-Frames an den Host übergeben?

1388
user_ABCD

Ich habe kürzlich ein Debian-Forum gesehen, in dem erwähnt wurde, dass Pause-Frames von der MAC-Schicht verworfen werden sollten. Andernfalls sollte der Treiber sie verwerfen. Ist das wahr? Wie drosselt ein Host tatsächlich den Verkehr, wenn er von einem Switch ein Pausenbild erhalten hat?

Ich versuche, die Ethernet-Flusskontrolle besser zu verstehen. Wenn die obige Aussage wahr ist, was bedeutet dann wirklich, dass sie an den Host übergeben wird?

3

2 Antworten auf die Frage

3
David Schwartz

Es gibt drei Möglichkeiten, mit der Flusssteuerung umzugehen:

  1. Wenn Sie überlastet sind, legen Sie Daten auf der Etage ab.
  2. Wenn Sie keinen Dienst für eine Anforderung von einer höheren Schicht bereitstellen können, weil Ihre lokale Warteschlange normalerweise voll ist, wird ein Fehler an diese höhere Schicht zurückgegeben.
  3. Sie benachrichtigen proaktiv höhere Ebenen, dass sie langsamer werden müssen.

Auf der Ethernet-Schicht wird Methode 3 durch Pause-Frames unterstützt. Häufig unterstützen höhere Ebenen nicht Methode 3, sondern unterstützen stattdessen Methode 2. Wenn sich unter einer Ebene eine Schicht befindet, die Methode 3 unterstützt, die darüber liegende Schicht jedoch nur Methode 2 unterstützt, kann die Weitergabe von Daten an niedrigere Ebenen vorübergehend unterbrochen werden, was zu einer Methode führt 2 für höhere Schichten.

Konkret ausgedrückt: Wenn Sie ein Pausenbild erhalten, stoppen Sie Ihre sendende Engine und stellen einen Timer ein, um die sendende Engine in der entsprechenden Zeit neu zu starten. Während das sendende Modul angehalten ist, werden Ihre lokalen Warteschlangen mit Daten von höheren Ebenen gefüllt. Wenn sie voll werden, geben Sie "beschäftigt" Fehler an die höheren Ebenen zurück und sie behandeln das, was jedoch angemessen ist.

Wie wird also ein Pause-Frame auf den Stack geschickt und die NIC wiederum den Sendeverkehr verlangsamen? Die Ethernet-Controller, die ich habe, unterstützen die Flusssteuerung, aber ich kann nicht feststellen, warum der Verkehr nicht "pausiert". user_ABCD vor 8 Jahren 0
Der Pause-Frame wird nicht auf den Stack geschickt. Die unterste Schicht des Stapels hört einfach auf, Bilder aus der Warteschlange zu lesen. Wenn die Warteschlange voll ist, erkennen höhere Ebenen dies, wenn ihre Funktionen zum Hinzufügen von Paketen zur Warteschlange fehlschlagen. (Lesen Sie den letzten Absatz.) David Schwartz vor 8 Jahren 4
Ich bin das alles ganz neu, aber wenn ich Sie richtig verstehe, was veranlaßt mich, Frames aus der Warteschlange zu lesen? Mit ethtool kann ich sehen, dass ich Pause-Frames vom Switch bekomme. Aber meine UDP-Anwendung verlangsamt sich in Bezug auf ein Bit / s nie. user_ABCD vor 8 Jahren 0
Ich weiß nicht genau, welche UDP-Anwendung (und welche Plattform) verwendet wird, aber normalerweise ist es der Mechanismus, der den Fall behandeln würde, in dem es keine Pause-Frames gab. Da Sie auch nicht lokale, nicht-Ethernet-Verbindungen überlasten können, können Sie sich bei UDP-Sendestimulation nicht auf Pause-Frames verlassen. In der Regel ist es nicht sinnvoll, zwei Mechanismen zu erstellen. Wenn Ihre Plattform die Informationen bis zum Benutzerbereich weitergibt, werden Sie sie normalerweise erkennen, da ein "sendto" auf einem nicht blockierenden UDP-Socket die Angabe "würde blockieren" zurückgeben würde. David Schwartz vor 8 Jahren 1
Hmmm. Ich bin mir ziemlich sicher, dass ich dich verstehe. Gibt es eine gute Methode, um festzustellen, ob ich die Pausenbilder überhaupt handle? Zwei Dinge, die ich derzeit weiß, sind, dass ich tatsächlich Pause-Frames (Ethtool) bekomme, und der Durchsatz (Wireshark) scheint sich nie zu ändern. Fast wie bei höheren Ebenen mache ich nie etwas, wenn ich die Pause-Frames erhalte. user_ABCD vor 8 Jahren 0
3
Spiff

Bisher war die Ethernet-Flusskontrolle ein fehlgeschlagener Versuch, da sie häufig Probleme mit dem Blockieren von Kopfzeilen verursacht. Switches sollten keine Pause-Frames an Hosts senden. Ich glaube, dass Cisco-Switches nicht für das Senden von Pausenbildern konfiguriert werden können. Durch die Aktivierung der Ethernet-Flusskontrolle auf einem Cisco-Switch werden lediglich die empfangenen Pausen-Frames berücksichtigt. Hosts sollten empfangene Pausenbilder ignorieren.

Wenn der Switch die Übertragung nicht verarbeiten kann, sollte er den Frame fallen lassen. Höhere Schichten, vor allem TCP, verwenden ausgelassene Frames, um zu wissen, wann eine Überlastung aufgetreten ist und wann sie zurückgesetzt werden muss. Wenn die Frames nicht gelöscht werden, schlägt die TCP- Überlastungssteuerung fehl, was in der Regel zu Bufferbloat führt .

Warum sollte ein Switch keine Pausenbilder senden? Ich habe einen Netgear-Switch, der sie an Hosts sendet. Wie sagt ein Host, dass ein anderer Host langsamer werden soll? user_ABCD vor 8 Jahren 0
@user_ABCD Informieren Sie sich über [Kopfzeile-Blockierung] (https://en.wikipedia.org/wiki/Head-of-line_blocking). Stellen Sie sich einen Switch vor, der mit einem GigE-Server, einem GigE-Client und einem 100-Mbps-Client verbunden ist, und beide Clients laden vom Server herunter. Der Eingabepuffer des Switches vom Server ist möglicherweise voll, da die Pakete nicht schnell genug an den 100-Mbit / s-Client gesendet werden können. Dann sendet der Switch einen Pausenrahmen an den Server, der den GigE-Client verletzt. Es stellt sich heraus, dass es besser ist, Verstopfungen zu bewältigen, indem Frames auf der Ethernet-Ebene fallen gelassen werden. Dadurch können die oberen Ebenen herausfinden, wann sie langsamer werden sollen. Spiff vor 8 Jahren 0
Dies beantwortet nicht wirklich das, was passiert, wenn Pausenrahmen _ar_ verwendet werden ... grawity vor 8 Jahren 0
@Spiff schlagen Sie vor, dass der Eingangspuffer eines Switches, sobald er voll ist, Pause-Frames an alle Ports mit aktivierter Flusskontrolle sendet? Das gesamte Netzwerk im Wesentlichen verlangsamen? user_ABCD vor 8 Jahren 0
@user_ABCD Nein, nur der Serverport in meinem Beispiel. Wenn für einen Switch separate Port-Eingangspuffer für jeden Port vorhanden sind und der Eingabepuffer * am Server-Port * aufgrund des langsamen Clients voll ist, sendet der Switch möglicherweise einen Pausenrahmen * nur an den Server *, wodurch der Server blockiert wird von anderen Clients wie dem schnellen Client. Spiff vor 8 Jahren 0
@Spiff, das hilft einem Haufen. Mein Switch-Datenblatt besagt, dass der Paketpufferspeicher dynamisch von den verwendeten Ports gemeinsam genutzt wird. Das heißt, sie haben nicht jeweils Eingangspuffer pro Port? user_ABCD vor 8 Jahren 0

Verwandte Probleme