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    [W:0.023 / U:0.656 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site