1. Speicherverwaltung
Die Speicherverwaltung entwickelt sich zweifellos weiter, ebenso wie DPDK. Wenn Sie mehr verwandte Bücher und Materialien lesen, geht es bei der Speicherverwaltung im Wesentlichen um Effizienz und Geschwindigkeit. Was bedeutet das? Volle Nutzung des Speichers, weniger Verschwendung oder keine Verschwendung, das ist Effizienz; die Geschwindigkeit der Speicherzuweisung und -wiederherstellung ist schnell, das ist Geschwindigkeit. In der vorherigen Analyse, warum in DPDK großer Speicher verwendet wird, geht es um Geschwindigkeit. Der Speicherpool kann in gewissem Maße sowohl die Effizienz als auch die Geschwindigkeit verbessern.
Einschließlich einiger In-Memory-Datenstrukturen, Verwaltungsmethoden und der Handhabung von Caches. Insbesondere wurde die Speicherverwaltung von statisch auf dynamisch umgestellt, was die Leistung weiter verbessert und die Effizienz der Speichernutzung erhöht. Dies ist die iterative Entwicklung von DPDK in kontinuierlichen praktischen Anwendungen.
2. Unterschiede zwischen den DPDK-Versionen 17 und 18
In DPDK17 und früher (weniger als DPDK18.11) kann davon ausgegangen werden, dass die Gesamtmethode der Speicherverwaltung grundsätzlich unverändert ist, nach dem Upgrade auf DPDK18 jedoch relativ große Änderungen stattgefunden haben. Im Folgenden werden hauptsächlich die Unterschiede betrachtet: 1. Für
die Speicherverwaltung großer Seiten
verwendet DPDK17 ein spezielles Hugetlbfs-Dateisystem, um Bereitstellungspunkte für großen Seitenspeicher bereitzustellen. Bieten Sie über die Konfiguration Zugriff auf Seiten unterschiedlicher Größe. Allerdings wurde in DPDK18 eine Einzeldateisegmentmethode (–single-file-segments) eingeführt, sodass weniger Dateien erstellt werden können, um ein schnelles Wachstum der Anzahl bei der Verwendung in der Cloud zu verhindern. Gleichzeitig wurde in DPDK18 auch der Speichermodus (–in-memory) eingeführt. Obwohl –huge-unlink in DPDK17 erstellte Dateien löschen darf, ist es immer noch nicht mit dem Speichermodus in DPDK18 zu vergleichen. Schließlich wird auch das Löschen erzeugt, und letzteres geschieht einfach im Speicher. Es eignet sich besser für Cloud-Szenarien.
2. Der Status der Speicherzuordnung
Ab DPDK18 kann der Speicher zur Laufzeit dynamisch erhöht oder verringert werden, dh die statische Speicherzuordnung wird eliminiert. Wenn DPDK17 in einer Umgebung ohne EAL ausgeführt wird, reserviert es den gesamten großen Seitenspeicher für seine eigene Sicherung, während DPDK18 nur den erforderlichen Speicher reserviert und ihn dann entsprechend der tatsächlichen Situation dynamisch erhöht.
3. Speichernutzung
In DPDK17 müssen die Parameter –m und –socket-mem verwendet werden, um die Speicherreservierung festzulegen, in DPDK18 sind diese jedoch als optional eingestuft. Natürlich kann auch –socket-limit verwendet werden, um den Speicher zu begrenzen einer einzelnen NUMA-Knotennutzung. Die höhere Version ist flexibler und kann den Speicher bequemer steuern.
4. IOVA-Adresskontinuität
In DPDK18 ist die Kontinuität von VA nicht garantiert die IOVA-Kontinuität. Mit anderen Worten: Du bist du und ich bin ich. Sie setzen Ihre fort, ich führe meine fort, aber die Anwendung ist davon nicht betroffen und daher flexibler. Allerdings muss DPDK17 während der Initialisierung eine große Menge kontinuierlichen IOVA-Speichers reservieren. Natürlich können Sie mit dem Parameter --legacy-mem dafür sorgen, dass das alte Speichermodell verwendet wird.
5. Unterschiedliches Speicherlayout
DPDK17 initialisiert das Speicherlayout, ist jedoch nicht in DPDK18 enthalten. Es kann während des Betriebs dynamisch geändert werden, sodass die zugehörigen Anwendungen auch die Speicherverarbeitung ändern.
6. Externer Speicher
DPDK18 unterstützt externen Speicher, DPDK17 jedoch nicht.
7. Sonstiges
Anders verhält es sich, wenn kein großer Seitenspeicher verwendet wird. Nach DPDK19 ist beispielsweise im vhost-user-Backend kein großer Seitenspeicher mehr erforderlich. DPDK18 fügt das oben genannte Speichermodell und mehr hinzu.
Weitere kleine Details wie gepackter_ring usw. werden in der nachfolgenden Codeanalyse abgefragt.
3. Zusammenfassung
Zumindest zu diesem Zeitpunkt ist die Speicherverwaltung untrennbar mit allen Programmen verbunden, sodass GC ein aktueller Forschungsschwerpunkt ist. Viele Sprachen wie Go, Java, Python usw. verfügen über einen eigenen GC. Tatsächlich ist GC eine leistungsfähigere Speicherverwaltung. Wenn Sie die Möglichkeit haben, Kontakt mit ihm aufzunehmen, werden Sie feststellen, dass die Speicherverwaltung in DPDK der jüngere Bruder vor ihnen ist. Andererseits wird DPDK definitiv seine eigene einzigartige Anwendung haben Szenarien. Einerseits ist das Wichtigste natürlich ein großer Speicher.
Das Erlernen der Frameworks anderer Menschen erfordert natürlich in der Anfangsphase ein gründliches Verständnis. Aber das ist zu schwer. In der späteren Phase liegt der Fokus darauf, die Eigenschaften anderer zu lernen, und nicht darauf, alles für immer zu essen. Wie das Sprichwort sagt: „Schauen Sie sich nur die Allgemeingültigkeit an.“