Ethernet+TCP/IP packet processing på multicore

[arte]

Hej,

Hur fungerar packet processing i en multicore miljö.

Har man en dedikerad core som alltid får ett interrupt från ethernet controllen och som gör all TCP/IP processing?
Då kanske tidigare paket och datastrukturer kan fastna i L1 cachen.

Alternativt så delar alla cores på uppgiften men då blir det mer L2/L3 accesser.

Någon som vet?

[kodar-holger]

Egentligen vet jag inte.

Jag tror alla alternativ förekommit i historien. Tanken med ett SMP-system är väl att det skall vara symmetrisk multiprocessning och alla processorer skall kunna hantera alla uppgifter lika bra. Men det behöver ju inte betyda att hårdvaran är gjord så in i minsta detalj. Hårdvaruinterrupten brukar väl mest leda till ett mjukvaruinterrupt som schemaläggs på något sätt. Hur schedulern väljer att fördela detta mellan processorer (kärnor) beror på OS.

Windows 2k som jag studerat lite närmre en gång i världen var inte så bra på att behålla saker på en kärna. Så en process hoppade vilt mellan processorerna och man hade något att vinna på att sätta thread affinity som det heter i windows. Har inte brytt mig på moderna system eftersom dom är tillräckligt snabba.

Att något skulle fastna i cachen behöver du inte oroa dig för. Då är hårdvaran felkonstruerad. Däremot kan det ju vara en fördel att låta en uppgift som tidigare körts på en kärna köra på samma kärna igen eftersom cachen kan ha saker kvar. Som sagt, Win2k var inte bra på detta.

Historien har även bjudit på assymetriska system där all IO sköttes av en processor och system där IO kunde skötas av alla men schedulern alltid kördes på en eller ....

[sodjan]

Som sagt, frågan går ju inte att svara på generellt.
Där jag jobbar så kan man koppla all TCP/IP hantering
hårt till en CPU (= core) som en TCP/IP optimering.

[arte]

Som sagt, frågan går ju inte att svara på generellt.
Där jag jobbar så kan man koppla all TCP/IP hantering
hårt till en CPU (= core) som en TCP/IP optimering.

Nyfiken på hur det fungerar i en modern server hall med t.ex en 8 core XEON som kör webserver + mysql. (Typ Amazon)

Verkar som att det är vanligt med avancerade Ethernet controllers som distruberar paketen direkt till en core.

Egentligen vet jag inte.

Jag tror alla alternativ förekommit i historien. Tanken med ett SMP-system är väl att det skall vara symmetrisk multiprocessning och alla processorer skall kunna hantera alla uppgifter lika bra. Men det behöver ju inte betyda att hårdvaran är gjord så in i minsta detalj. Hårdvaruinterrupten brukar väl mest leda till ett mjukvaruinterrupt som schemaläggs på något sätt. Hur schedulern väljer att fördela detta mellan processorer (kärnor) beror på OS.

Windows 2k som jag studerat lite närmre en gång i världen var inte så bra på att behålla saker på en kärna. Så en process hoppade vilt mellan processorerna och man hade något att vinna på att sätta thread affinity som det heter i windows. Har inte brytt mig på moderna system eftersom dom är tillräckligt snabba.

Att något skulle fastna i cachen behöver du inte oroa dig för. Då är hårdvaran felkonstruerad. Däremot kan det ju vara en fördel att låta en uppgift som tidigare körts på en kärna köra på samma kärna igen eftersom cachen kan ha saker kvar. Som sagt, Win2k var inte bra på detta.

Historien har även bjudit på assymetriska system där all IO sköttes av en processor och system där IO kunde skötas av alla men schedulern alltid kördes på en eller ....

Intressant!