Ez alapján azt mondanám, hogy 2 db 1 Gbps-es PPPoE kapcsolat is használható lenne vele, mert 4 magos, jut külön mag minden PPPoE-nek
Én vigyáznék ezzel a kijelentéssel!
Csak azért mert van 4 erős mag, és több mint 1 párhuzamosan élő pppoe session, még semmi garancia nincs arra h. 1-1 pppoe session teljes forgalmát 1-1 külön core kapja majd meg. Mert ahhoz ugyanúgy bele kellene tudni nézni a ppp csomagba, és pl. connection ID alapján szétdobni több cpu között. Ezek mind "1x NIC+több pppoe session" felállás esetére vonatkoznak (bár 1 NIC-en több pppoe session-nek nem tudom mi értelme, illetve technikailag ez egyáltalán kivitelezhető-e).
Több NIC, NIC-enként 1-1 pppoe session sem lesz sokkal jobb eset. Miért? Mert a NIC queue setup-ja is hasonlóan korlátolt. Pl adott egy NIC aminek 4 input queue-ja van, illetve 4 CPU core esetén ilyen összerendelés lesz: NIC1:queue1--> CPU1, NIC1:queue2--> CPU2, NIC1:queue3--> CPU3, NIC1:queue4--> CPU4. Ha ehhez jön egy NIC2, ott is hasonló lesz a hozzárendelés: NIC2:queue1--> CPU1, NIC2:queue2--> CPU2, NIC2:queue3--> CPU3, NIC2:queue4--> CPU4.
Ha továbbra is azt feltételezzük, h. minden "nemfelismert" forgalmat az első queue-ba pakol az RSS, akkor 2 db pppoe session 2 db NIC-en a következő hozzárendelést fogja kiterhelni:
NIC1:queue1--> CPU1, NIC2:queue1--> CPU1. Azaz mindkét pppoe session a cpu1-et fogja terhelni. Tehát még romlott is a teljesítmény 1 pppoe session esethez képest, ha cpu1 load-ja eléri így a 100%-ot.
Úgy tudom linux alatt erre olyan megoldás született, amikor más cpu is ki tudja venni adott NIC queue-ból a csomagot, nem csak a dedikáltan hozzárendelt. Ennek is van szerintem elég szép overhead-je ilyenkor, de talán a szumma nyereség nagyobb lesz vele, mint ami veszteséget okoz teljesítményben a queue-ok cpu-k közötti variálása. De valami linux network-ös guru ezt biztos meg tudja erősíteni, nekem itt már elfogy a szakmai tudásom.