Na przykład w przypadku asynchronicznego we / wy przy użyciu protokołu TCP / IP (przy użyciu POSIX poll / select lub bardziej zaawansowanego epoll, kqueue, poll_set, IOCP) sterownik sieciowy rozpoczyna przerwanie w innym (demultiplekser sprzętowy) Rdzenie procesora, odbierają wiadomości i zrzucają je do jednego (multiplekser) bufor na poziomie jądra. Następnie nasz akceptor wątków za pomocą epoll / kqueue / poll_set / IOCP otrzymuje z tego pojedynczego bufora listę deskryptorów gniazd wiadomości, które pojawiły się i ponownie rozproszą (demultiplekser) w wątkach (w puli wątków) działających na różnych rdzeniach procesora.

W skrócie wygląda to tak: przerwanie sprzętowe (demultiplekser sprzętowy) -> sterownik sieciowy w przestrzeni jądra (multiplekser) -> akceptor użytkownika w przestrzeni użytkownika za pomocą epoll / kqueue / poll_set / IOCP (demultiplekser)

Czy nie jest łatwiej i szybciej pozbyć się dwóch ostatnich linków i używać tylko „demultipleksera sprzętowego”?

Przykład. Jeśli nadejdzie pakiet sieciowy, karta sieciowa przerwie procesor. W większości dzisiejszych systemów przerwania te są rozmieszczone w rdzeniach. To znaczy. ta praca jest sprzętowym demultiplekserem. Po otrzymaniu takiej przerwy możemy natychmiast przetworzyć wiadomość tej sieci i poczekać na następne przerwanie. Wszystkie prace związane z demultipleksowaniem są wykonywane na poziomie sprzętu, przy użyciu przerwania procesora.

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

Czy możliwe jest podejście we wszystkich systemach Linux, w czasie rzeczywistym * nix, takich jak QNX, i czy istnieją projekty publiczne, w których takie podejście jest stosowane, może to być ngnix?

AKTUALIZACJA:

Prosta odpowiedź na moje pytanie -tak, mogę używać sprzętowego demultipleksowania używając/proc/irq/<N>/smp_affinity: http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux

Ale po drugie - nie jest to dobra rzecz, ponieważ różne części jednego pakietu mogą być obsługiwane przez różne rdzenie, a synchronizacja pamięci podręcznej może zająć trochę czasu (L1 (CoreX) -> L3-> L1 (CoreY)) dla spójności pamięci podręcznej :http://www.alexonlinux.com/why-interrupt-affinity-with-multiple-cores-is-not-such-a-good-thing

ROZWIĄZANIA:

Twarde wiązanie różnych adapterów ethernetowych (jego IRQ) z różnymi pojedynczymi rdzeniami procesoraużywaj dużych pakietów i małych wiadomości, gdy pakiet często zawiera całą wiadomość

PYTANIE: Ale może są jakieś lepsze rozwiązania, na przykład przy użyciu soft-IRQ (bez sprzętowego IRQ), gdy otrzymamy partię niektórych pakietów sieciowych z ręcznego adaptera sieciowego, czy istnieje?