Принципно, голяма част от gigabit ethernet драйверите подържат NAPI, примерно интел-ските и broadcom-ските. За 100мбит-ови карти не чак толкова (а и там се очаква процесорите да се справят с разните interrupt hogs явно). Software interrupts (softirqs) не би трябвало да имат нещо общо с QoS дисциплините, но не гарантирам 100%, просто така мисля.
"Самото шейпване" няма да бъде разпределено върху всички процесори, поне от гледна точка на паралелизъм, не мисля, просто няма отделен kernel thread, работещ върху всеки процесор и занимаващ се с това, подобно на ksoftirqd/x. Но вероятно работата, асоцирана с шейпването, ще се изпълнява на различен процесор в определено време, предполагам де
'>
"bridge" интерфейсът не е точно етернет-ски такъв...смисъл че за него не се вдига специално прекъсване (няма и как) за всеки пристигнал пакет, това си става индивидуално за всеки етернет интерфейс, така че в това отношение няма разлика. bridging-a е просто едно ниво на абстракция в цялата работа, така да се каже...
А иначе (спекулирам с това), броят на прекъсванията може да скочи, защото когато направиш bridge, вкарваш бридж-натите контролери в promiscuous режим и съвсем на теория, би следвало да се вдигат повече прекъсвания. Това е защото самите контролери, на хардуерно ниво, не са ли в promiscuous режим, пристигне ли фрейм дето не е адресиран за тях, не вдигат прекъсване.
Забавното е че смяната на МАК адрес (с ifconfig) при някои мрежови карти става точно така - хардуера не го подържа като функция, затова драйверът се изхитрява и минава в promiscuous mode, и почва да поема само фреймове с новия dst mac. Малко е грубо така, ама тва е
'>