At 09:25 PM 09/06/2000 +0100, you wrote: >> bridging. The frames are determined to have no valid destination (ie they >> are not broadcast and the destination mac address has not yet been >> learned...typical of initial startup) On a busy lan. there are thousands of >> frames from previous sessions on the wire which may be considered invalid >> by a bridge initially. These frames need to be discarded by the MAC layer; >> queuing them via netif_rx() is highly inefficient. > >netif_rx is the MAC layer. The driver interrupt handler simply grabs frames >and hands them up. Its undesirable to do long processing in irq handlers so >guess what - we dont Which should cause more shortages than our method, since X number of buffers may be queued erroneously. > >> illustrated here. 1) Linux doesnt free up memory fast enough for it to be >> re-used under heavy load, and 2) the eepro100 driver, after being trashed >> by a lack of memory, doesnt reset itself properly to a working condition. > >Your explanation doesn't fit your observations. I suspect #2 may have some >significance but that would be unrelated to the rate of resource usage. Then why does inserting a "mark_bh" after a kfree_skb alleviate the problem somewhat? it certainly doesnt add to the performance. if what you say is true, then the allocs attempting to replenish the buffers are failing erroneously, because the buffers are available. the buffer is being freed before the replenishment is attempted, so its a 1 to 1 relationship: 1) packet arrives 2) dest unknown, buffer is freed instead of passing it to netif_rx() 3) rx ring buff is replenished there should never be a buffer failure. Dennis - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
