lkml.org 
[lkml]   [1998]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.114 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site