> 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 > 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. > IS THERE A WAY TO ALLOW FREED MEMORY TO BE IMMEDIATELY (or > semi-immediately) AVAILABLE? It already is. Alan - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
