No, I really think it's more of a broken small part of the implementation.
So I think it's more a case of
- we may want to change the way incoming packets are handled to make it
perform better
and
- we may want to throttle excessive incoming interrupts
The first to make sure that we do the best damn job we can. That goes
without saying. However, the second part is really that _if_ networks
really will continue to outstrip CPU power (which I personally find very
unlikely indeed - it's just that network performance tends to go up in
bigger jumps, so people react more), then whatever we do we at some point
have to throttle the incoming flow when we determine that we cannot keep
up.
That's a fundamental fact. We can make things go faster, but networking is
an external entity, and very basic queueing theory applies. If you can't
keep up, you have to start dropping or it just gets worse. Chapter 1 of
any queueing theory book. Regardless of how fast you are, if you keep on
doubling the network speed, it will happen eventually.
Right now I don't see this as a problem in real life. It may become one,
although I doubt it. It tends to be a lot easier to upgrade machines than
to upgrade networks, and I'm not very worried about denial-of-service
attacks on internal networks (if you give access to your internal gigabit
network to people who want to do bad things you have mostly yourself to
blame). As such, I think people are just making a big thing out of
nothing.
The reason we don't get timer interrupts is not spl-levels. I bet it's
just a fairly simple issue of CPU starvation. Fixing it may not be simple:
fairness never is. But let's not panic.
Linus
-
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/