4

Ich versuche, die NAPI Funktionen auf Embedded Linux-Umgebung zu testen. Ich habe "pktgen" verwendet, um die große Anzahl von Paketen zu erzeugen, und versucht, die Anzahl der Interrupts meiner Netzwerkschnittstelle unter /proc/interrupts zu verifizieren.Wie Linux NAPI-Funktion zu testen?

Ich fand heraus, dass Interrupt-Anzahl ist vergleichsweise weniger als die Pakete generiert. Auch ich versuche, den 'netdev_budget' Wert von 1 bis 1000 (Standard ist 300) zu tun, so dass ich die Verringerung der Anzahl der Interrupts beobachten kann, wenn netdev_budget erhöht wird.

Allerdings scheint die Erhöhung des netdev_budget nicht zu helfen. Der Interrupt ist ähnlich der Unterbrechungszähler mit netdev_budget auf 300 gesetzt beobachtet

hier So sind meine Fragen:

  1. Was ist der Effekt von ‚netdev_budget‘ auf NAPI?

  2. Welche anderen Parameter kann/sollte ich einstellen, um die Änderungen in der Anzahl der Interrupts zu beobachten?

  3. Gibt es eine andere Art und Weise ich die NAPI Funktionalität zu testen unter Linux verwenden kann? (Außer direkt am Netzwerk-Treiber-Code suchen) ist

Jede Hilfe viel appreaciated.

Vielen Dank im Voraus.

+0

Test für ein "verrottendes Paket". Die Ankunft eines Rahmens genau während des Übergangs von Napi zurück zum Unterbrechungsmodus könnte unerkannt bleiben. Dieser Rahmen wird nicht behandelt, bis ein anderer ankommt, um einen Empfangsinterrupt auszulösen. – sawdust

+0

Hallo @sawdust danke für den Hinweis. Aber könnten Sie bitte Ihre Antwort ausarbeiten? Weil ich keine verlorenen Pakete sehe, es sei denn, ich vergrößere die Paket-/Rahmengröße. Was genau sollte ich tun, um zu überprüfen, ob es "verrottete Pakete" gibt? – sunisiha

+0

Ein verrottendes Paket ist kein verlorenes Paket. Es ist ein verzögertes Paket. Um einen solchen Fehler leicht zu bemerken, müssen Sie zeitlich abgestimmte Pakete, z. erwartet eine Antwort innerhalb von X Sekunden, und die Verbindung variiert zwischen einem Aktivitätsausbruch und einem Inaktivitätszeitraum. Die Umstände, um das Problem zu erzeugen, beinhalten ein Zeitfenster von vielleicht 10 Anweisungen. Aber Murphys Gesetz herrscht. Es kann schwierig sein, die Umstände zu schaffen, was teilweise erklärt, warum Treiber mit diesem Fehler veröffentlicht werden. – sawdust

Antwort

5

Ich schrieb eine comprehensive blog post about Linux network tuning, die alles über die Überwachung, Optimierung und Optimierung der Linux-Netzwerk-Stack (einschließlich der NAPI-Gewicht) erklärt. Schau mal.

Beachten Sie: einige Treiber nicht deaktivieren IRQs von der NIC, wenn NAPI startet. Sie sollen, aber manche tun es einfach nicht. Sie können dies überprüfen, indem Sie den harten IRQ-Handler im Treiber überprüfen, um festzustellen, ob harte IRQs deaktiviert sind.

Beachten Sie, dass harte IRQs in einigen Fällen wieder aktiviert werden, wie im Blogpost und unten erwähnt.

Soweit Ihre Fragen:

  1. Erhöhung netdev_budget erhöht sich die Anzahl der Pakete, die die NET_RX Softirq verarbeiten kann. Die Anzahl der Pakete, die verarbeitet werden können, ist ebenfalls durch ein Zeitlimit begrenzt, das nicht einstellbar ist. Dies verhindert, dass NET_RX softirq 100% der CPU-Auslastung verbraucht. Wenn das Gerät während seiner Zeitzuweisung nicht genügend Pakete zur Verarbeitung empfängt, werden hardirqs erneut freigegeben und NAPI ist deaktiviert.

  2. Sie können auch versuchen, Ihre IRQ-Koaleszenzeinstellungen für die Netzwerkkarte zu ändern, sofern diese unterstützt wird. Weitere Informationen darüber, wie dies zu tun ist und was genau das bedeutet, finden Sie im obigen Blogbeitrag.

  3. Sie sollten die Überwachung Ihrer /proc/net/softnet_stat Datei hinzufügen. Die Felder in dieser Datei können Ihnen dabei helfen herauszufinden, wie viele Pakete verarbeitet werden, ob Ihnen die Zeit davonläuft usw.

Eine Frage für Sie zu prüfen, um, wenn ich darf:

Warum tut Ihr hardirq Rate los? Es spielt wahrscheinlich keine Rolle, direkt. Der Hardirq-Handler in Ihrem NIC-Treiber sollte so wenig Arbeit wie möglich leisten, so dass die Ausführung eines Loses wahrscheinlich kein Problem für Ihr System darstellt. Wenn dies der Fall ist, sollten Sie dies sorgfältig messen, da es sehr unwahrscheinlich erscheint. Dennoch können Sie die IRQ-Koaleszenzeinstellungen und die IRQ-CPU-Affinität anpassen, um die Verarbeitung so zu verteilen, dass die Anzahl der hardirqs geändert wird, die von der NIC generiert bzw. von einer bestimmten CPU verarbeitet werden.

Sie sollten überlegen, ob Sie wahrscheinlich mehr an Paketverarbeitungsdurchsatz oder Paketverarbeitungslatenz interessiert sind. Je nachdem, welches Problem Sie haben, können Sie Ihren Netzwerkstapel entsprechend anpassen.

Denken Sie daran: Um Ihren Linux-Netzwerkstack vollständig zu optimieren und zu optimieren, müssen Sie jede Komponente überwachen und optimieren. Sie sind alle miteinander verwoben und es ist schwierig (und oft nicht ausreichend), nur einen einzigen Aspekt des Stapels zu überwachen und abzustimmen.