| |||||||||||||
Interrupt Latencies?Interrupt Latencies?Posted Feb 2, 2006 13:04 UTC (Thu) by simlo (subscriber, #10866)Parent article: Van Jacobson's network channels This way work is moved from kernel threads into userspace and into the interrupt handler. The amount of work needed to be done in interrupt context is probably also dependent on the number of channels, i.e. number of open network sockets. Wouldn't we open the machine up to an effective DDOS attack: Spam the network with small packets. If the machine has a lot of network sockets open the each interrupt takes a long time to excecute and at some point there isn't any cpu left. This issue is not so much problem if you run the handling in a thread (ksoftirqd) which will get lower priority as it starts to eat a lot of CPU. That way packets are dropped, but the rest of the system can run.
(Log in to post comments)
Interrupt Latencies? Posted Feb 3, 2006 0:34 UTC (Fri) by xoddam (subscriber, #2322) [Link] > This way work is moved from kernel threads into userspace and> into the interrupt handler. Packet handling isn't currently done in kernel threads, it's done in tasklets (OK, tasklets do run in a softirqd thread with the RT patch). That's a great way to hog a CPU, and the channel implementation fixes the problem by passing work to a thread, just as you suggest! In the slides you'll see that the example channel 'producer' code wakes the listening thread, so the 'consumer' is necessarily a task (but not necessarily a userspace one). An O(log n) search algorithm in the isr would indeed have high latency with a very large number of channels to choose from -- but there is no reason why the isr would have to select the final target amongst millions of user sockets; channels are just as good for intermediate queueing within the kernel as they are for delivery to userspace.
Interrupt Latencies? Posted Feb 8, 2006 9:02 UTC (Wed) by csamuel (✭ supporter ✭, #2624) [Link] Erm, actually VJ was removing code from the interrupt context - he gavethe example of the e1000 driver going from ~700 lines of code executed in an interrupt context down to ~400 lines.
|
|||||||||||||