lkml.org 
[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...)
    Date
    Hello!

    > That sounds like we're really spending most of our time actually handling
    > the physical interrupt. Is that right? That implies we don't even get to
    > the networking layer, we're just too slow getting the packet off the card.
    > And that's scary.

    Yes, it is correct. net_bh() does not work mainly not because it is bad,
    it just have too small slice of time to make any progress
    at high packet load. Timing measurements at moderate loads show,
    that 200MHz P-II could handle 100Mbit and more. But at some
    threshould (I guess, when average net_bh backlog size exceeds
    L1 cache size), exponential degradation starts.
    [ BTW there is one very interesting observation: in this state
    turning off L2 cache practically did not change timings. ]

    It is not so scary really. The solution to this "congestion up to
    death problem" is throttling card, when interrupts eat to much of time.
    In this case, at least some percent of packets is served and
    machine is not locked.

    But this percent is still too low to handle pretty usual situation:

    One Linux-2.1 box make usual UDP send() in loop, another one receives.
    If sender does not make any application level flow control
    (again usual situation), Linux receiver drop almost all the packets.

    When we bypass net_bh, and queue packets directly to receiver
    queue on device interrupt, total packet processing time reduces
    to the value, when receiver cannot be congested by single 100Mbit
    interface. Compare this with net_bh, when we are able to receive only
    about 10Kpps on 233 MHz cpu and forward about 30Kpps, losing >99% of packets
    at higher rates.

    It is paradox: we have disguisting highly latent transmittion path,
    which could be much better, however 2.1 can send much faster than
    it is able to receive. 8) BTW NT cannot congest 2.1 8)8)8)

    Alexey

    -
    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:3.095 / U:0.336 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site