On Thu, Feb 06, 2003 at 05:16:21AM -0500, Lennert Buytenhek wrote:
> The fact that noone else is having this problem points in the direction
> of your 'ARM based embedded system' or the ethernet drivers used therein.
We are not yet done with our analysis.
As further investigation turned out, it does not seem to be a memory leak.
sk_buffs are allocated and freed, just the memory is not given back
to the userspace after being done.
It seems, that the data are not sent out fast enough at the second interface.
Our analysis of the situation currently is as follows:
When a frame enters the system, it is still in layer 2. If the destination
is local (or the packet is to be _routed_) it will be received via
netif_rx() and enter layer 3 (IP). At this point a queuing is done
and the queue has a maximum number of entries; further packets are
dropped. (The same seems to be true for sending from layer 3.)
Therefore without bridging an upper limit of queued packets (in
several queues) applies.
When a packet stays in the bridge (layer 2), no queueing is ever done,
so there is no upper limit on the frames being received and the
system will eat up all memory, if the frames are not processed or
sent out as fast as they are coming in.
Could you (or somebody else) confirm this analysis. If it is correct,
it means that we have to implement some limit to the number of frames
in the bridge. If not, we have to re-analyze the behaviour...
(If somebody wants to test himself: pump UDP data (no handshake)
through the bridge and watch "free" and "/proc/slabinfo"...)
Best regards,
Lutz
--
[EMAIL PROTECTED] Innominate Security Technologies AG
Dr.-Ing. Lutz J�nicke networking people
Engineer/Software Engineer http://www.innominate.com/
Tel ++49 30 6392-3308 Fax ++49 30 6392-3307
_______________________________________________
Bridge mailing list
[EMAIL PROTECTED]
http://www.math.leidenuniv.nl/mailman/listinfo/bridge
