Например, для асинхронного ввода-вывода с использованием TCP / IP (с использованием опроса / выбора POSIX или более сложного epoll, kqueue, poll_set, IOCP) сетевой драйвер запускается с прерыванием в другом (аппаратный демультиплексорЦП-ядра, принимает сообщения и сбрасывает их в одномультиплексор) буфер на уровне ядра. Затем наш потокоприемник с помощью epoll / kqueue / poll_set / IOCP получает из этого единственного буфера список дескрипторов сокетов сообщений, которые пришли и снова разбрасываются (демультиплексор) между потоками (в пуле потоков), работающими на разных процессорных ядрах.

Вкратце схема выглядит так: аппаратное прерывание (аппаратный демультиплексор) -> сетевой драйвер в пространстве ядра (мультиплексор) -> акцептор пользователя в пространстве пользователя с помощью epoll / kqueue / poll_set / IOCP (демультиплексор)

Разве не проще и быстрее избавиться от последних двух ссылок и использовать только «аппаратный демультиплексор»?

Пример. Если сетевой пакет прибывает, сетевая карта будет прерывать процессор. В большинстве современных систем эти прерывания распределяются по ядрам. То есть эта работа является аппаратным демультиплексором. После получения такого прерывания мы можем немедленно обработать сообщение этой сети и дождаться следующего прерывания. Вся работа по демультиплексированию выполняется на уровне оборудования с использованием прерывания процессора.

В Cortex-A5 MPCore:http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0434b/CCHDBEBE.html

Реален ли подход во всех Linux, в * nix в реальном времени, например, в QNX, и есть ли публичные проекты, где этот подход используется, может быть ngnix?

ОБНОВИТЬ:

Простой ответ на мой вопрос -да, я могу использовать аппаратное демультиплексирование используя/proc/irq/<N>/smp_affinity: http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux

Но второе замечание - это не очень хорошая вещь, потому что разные части одного пакета могут обрабатываться разными ядрами, и может потребоваться время для синхронизации кэширования (L1 (CoreX) -> L3-> L1 (CoreY)) для когерентности кэша. :http://www.alexonlinux.com/why-interrupt-affinity-with-multiple-cores-is-not-such-a-good-thing

РЕШЕНИЯ:

жестко привязать разные сетевые адаптеры (их IRQ) к разным одиночным процессорамиспользовать большие пакеты и маленькие сообщения, когда пакет часто содержит целое сообщение полностью

ВОПРОС: Но, может быть, есть и лучшие решения, например, использование мягкого IRQ (без аппаратного IRQ), когда мы получаем пакет некоторых сетевых пакетов от сетевого адаптера вручную?