PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,619
- Punkte für Reaktionen
- 1,947
- Punkte
- 113
Das steht doch in dem Punkt deutlich drin ... es werden die (Netzwerk-)"Pakete" beschleunigt und zwar dahingehend bzw. dadurch, daß innerhalb einer einmal eingerichteten Verbindung (bestehend aus den beiden Endpunkten, die i.d.R. durch die IP-Adresse und die Portnummer beschrieben sind) nicht mehr alle Pakete den Weg über die CPU des Routers nehmen, sondern nach dem simplen Austausch weniger Bytes im Paket (wobei die zu tauschenden Daten in entsprechenden "Tabellen" beschrieben sind und diese Operationen "in Hardware" erfolgen, was aber auch nur ein Euphemismus für einen sehr spezialisierten Prozessor ist - genauso wie das ein Crypto-Prozessor für das Ver- und Entschlüsseln wäre) direkt zum WAN-Modem oder eben zum LAN-Switch (je nach Ziel) weitergeleitet werden (zu sehen u.a. in diesem "Blockdiagramm": https://www.electronicsdatasheets.com/download/51c42036e34e246e490000d9.pdf - ich finde gerade keinen anderen Link).
Genau deshalb gibt es diese Paketbeschleunigung auch bereits seit der 7390 (und seit einigen Versionen auch als Einstellmöglichkeit auf der Support-Seite) - die Chipsätze davor (AR9 und UR9) hatten m.W. dieses Feature auch noch nicht. Und da es das bei AVM auch - zumindest teilweise - in Software gibt, gibt es für diesen Paket-Beschleuniger (aka "packet accelerator" oder auch "avm_pa" in der Driver-Implementierung) auch diese zweigeteilte Abschaltung - entweder komplett (dann geht jedes Paket über den Kernel-Code zum Routing und der Durchsatz geht erheblich zurück) oder nur das Ignorieren der Hardware-Unterstützung aus dem Chipset.
Die bei AVM verbleibende Software-Acceleration besteht aus einigen Optimierungen beim Weiterreichen der Pakete an den AVM-Stack - genauer kann man sich das in den Kernel-Quellen ansehen, denn dieser Teil ist (sicherlich auch deshalb, weil er direkt im Kernel sitzt und ohne Schnittstellen, die GPL-Lizenzen erzwingen, nicht voll funktionieren würde und nicht nur, weil AVM es halt so wollte - an anderen Stellen sind sie da ja wesentlich "schweigsamer") Bestandteil des von AVM veröffentlichten OpenSource-Pakets, auch wenn man sich daraus die tatsächliche Programmierung der PPE (Protocol Processor Engine) nur mühsam zusammenreimen kann (und man mit den Lantiq-Patches, die man z.B. bei einigen OpenWRT-Repos findet, besser bedient ist).
Auch bei "Software-PA" muß natürlich jedes Paket erst mal durch den Switch in die CPU und irgendwann dann weiter zum Modem - auch das ist also deutlich langsamer, als die Benutzung der Hardware-Unterstützung, wo die Software dann tatsächlich nur bei neuen Verbindungen den Pfad einrichtet bzw. ihn beim Schließen wieder abräumt (bei TCP anhand von Flags, bei UDP i.d.R. nach Zeit) und ansonsten mit dem Datenverkehr zwischen LAN-Client und Internet nichts weiter zu tun hat.
Es wird dann praktisch nur festgelegt, welche Bedingungen ein Paket erfüllen muß, um zusätzlich noch zur CPU geschickt zu werden (bei TCP wäre das z.B. ein gesetztes FIN-Bit als Zeichen, daß die Verbindung jetzt geschlossen wurde/wird) - erst wenn dieses Paket dann eintrifft, kümmert sich die CPU wieder aktiv um die (Re-)Programmierung der PPE. Alles dazwischen interessiert sie nicht - selbst die Pakete in beiden Richtungen werden selbständig von der PPE gezählt.
Beim Verbindungsaufbau gibt es logischerweise noch keine passenden Einträge für die PPE, daher gehen solche Pakete dann automatisch an die CPU, die die notwendigen Einträge dann vornimmt (wenn der Traffic erlaubt ist). Alles danach wird direkt weitergeleitet - bis es ein Paket gibt, das den Zustand der Verbindung wieder ändert oder bis die "life-time" einer Verbindung, bei der es kein explizites "Schließen" gibt, abgelaufen ist.
Diese Art der Beschleunigung gab/gibt es jedenfalls auch schon in früheren Chipsets von Infineon/Lantiq/Intel (oder künftig wohl MaxLinear), die noch nicht über eine DEU (Data Encryption Unit) verfügten. Daß AVM einen Switch für die (De-)Aktivierung der DEU vorgesehen hätte, habe ich noch nicht gesehen - muß aber nichts heißen.
Genau deshalb gibt es diese Paketbeschleunigung auch bereits seit der 7390 (und seit einigen Versionen auch als Einstellmöglichkeit auf der Support-Seite) - die Chipsätze davor (AR9 und UR9) hatten m.W. dieses Feature auch noch nicht. Und da es das bei AVM auch - zumindest teilweise - in Software gibt, gibt es für diesen Paket-Beschleuniger (aka "packet accelerator" oder auch "avm_pa" in der Driver-Implementierung) auch diese zweigeteilte Abschaltung - entweder komplett (dann geht jedes Paket über den Kernel-Code zum Routing und der Durchsatz geht erheblich zurück) oder nur das Ignorieren der Hardware-Unterstützung aus dem Chipset.
Die bei AVM verbleibende Software-Acceleration besteht aus einigen Optimierungen beim Weiterreichen der Pakete an den AVM-Stack - genauer kann man sich das in den Kernel-Quellen ansehen, denn dieser Teil ist (sicherlich auch deshalb, weil er direkt im Kernel sitzt und ohne Schnittstellen, die GPL-Lizenzen erzwingen, nicht voll funktionieren würde und nicht nur, weil AVM es halt so wollte - an anderen Stellen sind sie da ja wesentlich "schweigsamer") Bestandteil des von AVM veröffentlichten OpenSource-Pakets, auch wenn man sich daraus die tatsächliche Programmierung der PPE (Protocol Processor Engine) nur mühsam zusammenreimen kann (und man mit den Lantiq-Patches, die man z.B. bei einigen OpenWRT-Repos findet, besser bedient ist).
Auch bei "Software-PA" muß natürlich jedes Paket erst mal durch den Switch in die CPU und irgendwann dann weiter zum Modem - auch das ist also deutlich langsamer, als die Benutzung der Hardware-Unterstützung, wo die Software dann tatsächlich nur bei neuen Verbindungen den Pfad einrichtet bzw. ihn beim Schließen wieder abräumt (bei TCP anhand von Flags, bei UDP i.d.R. nach Zeit) und ansonsten mit dem Datenverkehr zwischen LAN-Client und Internet nichts weiter zu tun hat.
Es wird dann praktisch nur festgelegt, welche Bedingungen ein Paket erfüllen muß, um zusätzlich noch zur CPU geschickt zu werden (bei TCP wäre das z.B. ein gesetztes FIN-Bit als Zeichen, daß die Verbindung jetzt geschlossen wurde/wird) - erst wenn dieses Paket dann eintrifft, kümmert sich die CPU wieder aktiv um die (Re-)Programmierung der PPE. Alles dazwischen interessiert sie nicht - selbst die Pakete in beiden Richtungen werden selbständig von der PPE gezählt.
Beim Verbindungsaufbau gibt es logischerweise noch keine passenden Einträge für die PPE, daher gehen solche Pakete dann automatisch an die CPU, die die notwendigen Einträge dann vornimmt (wenn der Traffic erlaubt ist). Alles danach wird direkt weitergeleitet - bis es ein Paket gibt, das den Zustand der Verbindung wieder ändert oder bis die "life-time" einer Verbindung, bei der es kein explizites "Schließen" gibt, abgelaufen ist.
Diese Art der Beschleunigung gab/gibt es jedenfalls auch schon in früheren Chipsets von Infineon/Lantiq/Intel (oder künftig wohl MaxLinear), die noch nicht über eine DEU (Data Encryption Unit) verfügten. Daß AVM einen Switch für die (De-)Aktivierung der DEU vorgesehen hätte, habe ich noch nicht gesehen - muß aber nichts heißen.
