Zero-Copy-Sockets
- Ersteller döna
- Erstellt am
Naja, es ist realtiv gefahrlos einzuschalten. Aber in der Praxis eher irrelevant, weshalb es halt eine Option geblieben ist. Du breuchst einmal Unterstützung durch die NIC. Die einzigen Karten die diese meines Wissens nach haben sind if_ti(4), die zwar legendär gut sind aber schon seit Jahren nicht mehr gebaut werden. Dann brauchst du eine MTU, die größer als die Page Size deiner CPU-Architektur ist. Das wäre für ein FreeBSD/i386 also mindestens 4097 Byte. Damit müssrn das Netzwerkequipment und die Gegenseiten erstmal klarkommen. Kurz um, du kannst es vergessen. Wenn du Socket-Tuning möchtest, drehe lieber die Buffer für Sockets höher. Das sind die Sysctl net.inet.tcp.recvspace und net.inet.tcp.sendspace. Das bringt mehr und problemloser.
Danke für die Antwort.
Ich verstehe bloß nicht, wo mit Jumbo-Pages (= 9K) das Problem beim send
mit der MTU liegen soll.
Und beim Receive muss doch einfach nur die physikalische Seite vom
Userspace-Puffer umgebogen werden auf die im Kernel allokierte.
(Klar, dass der Puffer im Userspace page-aligned und ein vielfaches der
PAGE_SIZE sein muss.)
Was machen die beiden sysctls eigentlich? Setzen die den Buffersize höher
und damit die Anzahl der vom Socket vorhergesehenen Seiten zum Flippen
vom Kernel- in den Userspace?
Ich verstehe bloß nicht, wo mit Jumbo-Pages (= 9K) das Problem beim send
mit der MTU liegen soll.
Und beim Receive muss doch einfach nur die physikalische Seite vom
Userspace-Puffer umgebogen werden auf die im Kernel allokierte.
(Klar, dass der Puffer im Userspace page-aligned und ein vielfaches der
PAGE_SIZE sein muss.)
Was machen die beiden sysctls eigentlich? Setzen die den Buffersize höher
und damit die Anzahl der vom Socket vorhergesehenen Seiten zum Flippen
vom Kernel- in den Userspace?
Beim Senden dürfte es kein MTU Problem geben. Dein Programm schreibt ja in den Sockel, ohne diese Dinge zu kennen. Die Aufteilung auf die Pakete mit ihrer MTU passiert erst darunter, ohne dass das Programm etwas davon mitbekommt. Das Programm muss nur darauf achten, den Socket nicht neu zu beschreiben, bevor der Kernel ihn freigegeben hat.
Interessanter ist die Sache beim Empfangen. Die NIC empfängt ein Paket, verwurstet es und am Ende landet es im Socket, wo die Anwendung es lesen kann. Damit das per Zero Copy passieren kann, müssen die Pakete wie gesagt größer der Page Size sein. Auch müssen sie page aligned im Socket landen. Ersteres erreicht man über die MTU, Jumbo Frames lösen das Problem. Zumindest im Labor, in der Praxis sind viele Netzwerke in Teilen so alt oder auf so minderwertiger Hardware gebaut, dass man sie nicht problemlos nutzen kann. Letzteres ist das Problem, denn da muss die Karte die Magie machen. Und das können die wenigsten und an dem Punkt ist diese an sich gute Idee letztendlich auch gescheitert. Man möge ich korrigieren, aber ich meine wie oben gesagt, dass der einzige NIC nach wie vor der alte Tigon ist. Das man später, wenn man den Kram im Kernel hat, die Seite nur einmal verbiegen muss, stimmt schon. Aber man muss halt erstmal bis zu dem Punkt kommen.
Meine beiden Sysctl haben damit gar nichts zu tun. Sie geben einfach an, wie viele Daten die Sockets maximal zwischenspeichern können, bis sie keine Daten mehr annehmen. Sozusagen. Es gibt da noch einige mehr, mit dem man das Netzwerk tunen kann. Auch TSO und TCO sind da zu nennen. Aber das weicht dann doch recht weit vom Thema ab.
Interessanter ist die Sache beim Empfangen. Die NIC empfängt ein Paket, verwurstet es und am Ende landet es im Socket, wo die Anwendung es lesen kann. Damit das per Zero Copy passieren kann, müssen die Pakete wie gesagt größer der Page Size sein. Auch müssen sie page aligned im Socket landen. Ersteres erreicht man über die MTU, Jumbo Frames lösen das Problem. Zumindest im Labor, in der Praxis sind viele Netzwerke in Teilen so alt oder auf so minderwertiger Hardware gebaut, dass man sie nicht problemlos nutzen kann. Letzteres ist das Problem, denn da muss die Karte die Magie machen. Und das können die wenigsten und an dem Punkt ist diese an sich gute Idee letztendlich auch gescheitert. Man möge ich korrigieren, aber ich meine wie oben gesagt, dass der einzige NIC nach wie vor der alte Tigon ist. Das man später, wenn man den Kram im Kernel hat, die Seite nur einmal verbiegen muss, stimmt schon. Aber man muss halt erstmal bis zu dem Punkt kommen.
Meine beiden Sysctl haben damit gar nichts zu tun. Sie geben einfach an, wie viele Daten die Sockets maximal zwischenspeichern können, bis sie keine Daten mehr annehmen. Sozusagen. Es gibt da noch einige mehr, mit dem man das Netzwerk tunen kann. Auch TSO und TCO sind da zu nennen. Aber das weicht dann doch recht weit vom Thema ab.
Nachdem ich mich jetzt mal für's receive durch den Kernelsource entlang
des Pfads von der HW zum Userspace gelesen habe, habe ich das von
dir (Yamagi) angesprochene Problem auch verstanden.
Es liegt wohl daran, dass man im Allgemeinen garantieren müsste, dass
die empfangenen Nutzdaten page-aligned sind. Möglicherweise schafft
man dieses, indem man, wie z.B. für die e100 die RFDs
(Receive-Frame-Deskriptoren) jeweilig anpasst.
Man kann sich natürlich auch überlegen, wie man ansonsten die (nicht)
aligned-ten Daten vom Socketpuffer in den Userspace bekommt wenn
man möglichst wenig kopieren will.
@Yamagi: Ich glaub die Chelsio-Karte (cxgb) unterstützt das bisherige
Zero-Copy auch.
des Pfads von der HW zum Userspace gelesen habe, habe ich das von
dir (Yamagi) angesprochene Problem auch verstanden.
Es liegt wohl daran, dass man im Allgemeinen garantieren müsste, dass
die empfangenen Nutzdaten page-aligned sind. Möglicherweise schafft
man dieses, indem man, wie z.B. für die e100 die RFDs
(Receive-Frame-Deskriptoren) jeweilig anpasst.
Man kann sich natürlich auch überlegen, wie man ansonsten die (nicht)
aligned-ten Daten vom Socketpuffer in den Userspace bekommt wenn
man möglichst wenig kopieren will.
@Yamagi: Ich glaub die Chelsio-Karte (cxgb) unterstützt das bisherige
Zero-Copy auch.
