At 09:57 AM 09/06/2000 +0100, Alan Cox wrote: >> no, these packets arent being queued...they are being dumped before being >> queued (why would you queue a packet that you know is bad?). Thats the issue. > >These frames have what - framing errors and bad crc ? Arghhh..I'll outline this again. The adapter is in promiscuous mode for 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. > >> So, are you saying that there is no way to explicity free memory for >> immediate use? The issue with the eepro driver is that it doesnt recover >> even when the traffic subsides, which has nothing to do with the fact that >> there is no memory available to fill the buffers in the first place. > >I still dont think main memory is related to the current eepro100 problems at >all - lack of it or otherwise. If you fired invalid frames at it then Im >convinced it doesnt. They are not invalid frames. I dont understand why you cant understand this. There are 2 problems 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. Im sure the penguins will accuse me of something here, but the same test on a 'BSD box chugs along nicely without even breathing hard, even on a slow cpu system The (fxp) eepro100 driver never runs out of memory because the buffers are being freed faster than the traffic is arriving and freebsd allows the memory to be used immediately. The "problem" with linux is that, even though the memory has been freed, the network card driver (and it doesnt matter which driver it is...the tulip driver runs out of memory also).. cant get the buffers, causing the driver to not be able to replenish its receive ring. The eepro100 driver problem is not so much that it runs out of buffers (thats Linux's fault), but that it doesnt recover from the condition when buffers are available. Rather when whining about the validity of the test, how about a solution? The test merely accelerates the occurrance of an obvious problem. IS THERE A WAY TO ALLOW FREED MEMORY TO BE IMMEDIATELY (or semi-immediately) AVAILABLE? Dennis - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
