Messages in this thread | | | Date | Mon, 21 Sep 1998 20:20:43 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...) |
| |
On Mon, 21 Sep 1998, Richard Gooch wrote:
> Wouldn't these problems with sharing interrupts be solved by removing > the SA_INTERRUPT flag entirely and simply having interrupt handlers > return a flag indicating that it doesn't want bottom halves called? > The semantics could be either: > > - I didn't do anything that requires a BH > > or: > - I'm being called so fast that BH processing may kill the machine.
Keep in mind the following:
- Any cycle that is executed in interrupt context and that could be executed in some post-processing (as BH handlers) is stolen by your code for the general scheduling policy of the system.
- An interrupt occurs on 1 CPU generally for 1 event. So latency of cycles that have been stolen in interrupt context may be time lost on SMP machine even if you have TONS of processors.
Donnot apply blindly 'has been' systems design to modern systems. Part of 'has been' may 'still be', but part of 'has been' _is_ 'no more'.
Unless the processing of the interrupt is _really_ very short, an interrupt handler must just catch the event(s) and queue it (them) for post processing (as BH handlers).
The post processing (BH) can be multi-threaded on SMP machine as follow:
- Let BH handlers process small batches of events at a time. - Be clever enough to minimize synchronization and maximize parallelism. - With small batches the L1/L2 caching will not be defeated.
> With the latter semantic perhaps an alternative would be for the core > interrupt handling and dispatch system to take note of interrupt > flooding and start dropping BH processing. If the code to implement > this can be fast enough, would this be the answer to SA_INTERRUPT?
When you are interrupt-flooded, the only code you are sure to execute is the interrupt handler (and the real time), so you may implement some heuristic in the interrupt handler to detect the attack. You may base this heuristic on event counters, as seen from the interrupt handlers and as seen from the post processing and take into account the real time (jiffies), since the real time interrupt must still be alive.
For example in case on network flooding, you can implement some soft disabling of the network board from the interrupt handler that allows to restart the data flow later.
I would like a network data flow control that works this way:
1 - Throw away the current packet, if you cannot have ressources for a next one. This prevent from having to restart the pump after resources will get available.
2 - Implement a 'throw away on resource lack' strategy (from interrupt routine) that is as fast as possible. This will allow to resist to not too hard attacks.
3 - Implement a 'flood detection' heuristic based on event counters and real time and the soft disabling as decribed above.
4 - In normal case, just queue the event for post processing (as BH handlers) and implement multi-threaded post processing in order to maximize SMP scalability.
End of dream, unless the network stack work this way. :-) BTW, my knowledge of existing network stacks is closed to nil. This makes me 'has been' immune at least on this domain. ;-)
Regards, Gerard.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |