Tom Chen wrote:

In the NICDrv test01 (promiscuous mode rx/tx test using netperf and
snoop), I noticed that my driver runs out of resources. I am using
"desballoc" to pre- allocate message blocks and the OS should return
data buffer once it consumes the message. It seems that the driver
does not get data buffer back in time and has to rely heavily on
"copy" mode which I used when there are not enough free data buffer
inside driver and has to dynamically allocate new message block using
"allocb", copy new packet to it, then send to OS. But gradually,
machine becomes very slow, probably due to large number of memory
held by OS.

Have you traced through the full lifecycle of some of your buffers to make sure that you're recycling payload correctly and not leaking memory yourself. A good way to look for leaks is to do a test run with kmem_flags set to 0xf then drop into kmdb and do a $<systemdump to force a panic. When the system reboots you can then do an mdb ::findleaks on the core to check for large numbers of leaked buffers, and who allocated them.


I am wondering in what condition can this situation happen? why OS
does not return data buffer back to driver quickly? if a packet
driver sent is wong, the OS should discard it immediately and release
the memory, isn't it?


Part of the problem with using desballoc() is that the stack may hang onto your memory for an arbitrarily long time. When using TCP there's generally two return scenarious:

- the buffer is returned from the context of the driver receive handler (possibly because it's just ACKing a TX). - the buffer is returned from the context of the read() call on the socket head when the data is copied out to user space and thus the buffer is no longer needed.

The amount of time taken in the second scenario is clearly heavily dependent on the app.

  Paul

--
===================================
Paul Durrant
http://www.linkedin.com/in/pdurrant
===================================
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to