lkml.org 
[lkml]   [1998]   [Sep]   [20]   [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 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
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


-
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    [from the cache]
©2003-2011 Jasper Spaans