On Sat, 19 Sep 1998, Linus Torvalds wrote:
> On Sun, 20 Sep 1998, Donald Becker wrote:
> >
> > > 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.
> >
> > Hmmm, I don't see this as a dropping issue. I see as
> > A simple interrupt flooding problem
> > A reason to reduce the work done in netif_rx(), so that dropped packets
> > haven't wasted much work.
> > A reason putting eth_type_trans() in the drivers was a bad idea (see
> > previous point)
>
> Note that "dropping" was meant to be more generic than just dropping a
> packet. We can decide to drop packets proactively by just deciding to
> disable the interface completely for a while, to make sure it doesn't
> flood us with interrupts. That's obviously fairly extreme, but it might be
> the simplest answer (the driver could even decide on its own to disable
I sure hope this would be a -last- ditch effort to prevent
interupt flooding . In my router I sure wouldn't want this
to be a -os- made decision I'd definatly would want me to be
able to turn it off or on as I see needed .
> itself if it sees overlong backlog queues, as long as we'd have some way
> of enabling it again when the queue empties - by a timer or something).
>
> > I pretty much concur. Except that skipping clock ticks is a Bad Thing. I
> > don't mind dropping packets or characters, but if Xclock is wrong then I'm
> > later for meetings than I intended to be ;->
>
> If we do indeed skip clock-ticks, the only thing that should be able to
> make that happen is somebody holding an interrupt lock for too damned
> long. MUCH too long. Unrealistically long, in fact.
>
> I don't think that's the case, I think it's the other bh routines being
> starved or something, so that while the clock is being updated, timers
> nerver occur because they occur in bottom half entries too (and are thus
> shut out if net_bh() runs forever).
>
> So the real-time clock should be ok unless the CPU really is spending all
> its time in the network interrupt handler (as opposed to net_bh()). And
> that in turn implies either a bad network driver or just that the network
> is so fast that we can't even receive the packets in time, much less
> actually process them..
>
> Linus
tia, JimL
+-----------------------------------------------------------------------+
| James W. Laferriere - Network Engineer - babydr@nwrain.net |
| System Techniques - 25416 - 22nd S. - Des-Moines, WA 98198 |
| Give me VMS -or- Give me Linux -but- only on AXP |
+-----------------------------------------------------------------------+
-
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/