[Top] [All Lists]

Re: Queue and SMP locking discussion (was Re: 3c59x.c)

To: netdev@xxxxxxxxxxx
Subject: Re: Queue and SMP locking discussion (was Re: 3c59x.c)
From: Michael Richardson <mcr@xxxxxxxxxxx>
Date: Fri, 31 Mar 2000 14:08:19 -0500
In-reply-to: Your message of "Fri, 31 Mar 2000 22:46:15 +0400." <200003311846.WAA00485@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
>>>>> "kuznet" == kuznet  <kuznet@xxxxxxxxxxxxx> writes:
    kuznet> Khm... Please, get some simple benchmark applet sort of netperf
    kuznet> and enjoy with this impossible phenomenon on single 100Mbit
    kuznet> interface.  Despite of all the "max job on interrupt" linux-2.2

  Alexey is totally right. Even with maximum of work on interrupt, a Linux
box facing full speed fast ethernet simply stops. 

    kuznet> never leaves irq handler and does no job in result. BSD (and NT,
    kuznet> by a strange reason) with their silly approach _work_ at any load
    kuznet> level, by the way.

  That's is essentially because BSD go and process the packet, discarding
thousands at the NIC layer (due to it being out of receive buffers), and
therefore get a little bit of work done.
  Linux tries (smartly) to empty the entire queue from the network card
before processing any packets, and since it just can't keep up, period, it
never finishes, regardless of max-interrupt-work --- there is immediately
another interrupt.

  NT "solves" the problem because most of its drivers are actually threads,
so they must submit to scheduling as well. (that's also what makes them so

  To solve the the problem, you have to do QoS on CPU scheduling, or offload
the bulk of the work to smarter hardware... 
   :!mcr!:            |  Solidum Systems Corporation,
   Michael Richardson |For a better connected world,where data flows faster<tm>
        mailto:mcr@xxxxxxxxxxxxxxxxxxxxxx       mailto:mcr@xxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>