lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] add 2 netif for 2 ETH MAC´s to have 2 buffer pools


From: Kieran Mansley
Subject: Re: [lwip-users] add 2 netif for 2 ETH MAC´s to have 2 buffer pools
Date: Mon, 16 May 2011 10:11:58 +0100

On Mon, 2011-05-16 at 11:00 +0200, Thomas Richter (TCD - DE/Dresden)
wrote:

> What do you think, is it a possible way?

It is, but it will double the memory used for packets.  It sounds like
the problem you're trying to solve is that connections on one netif are
using all the packet buffers, leaving none or few for connections on the
other.  Giving each netif a separate pool will stop this, but if you can
afford the memory it might just be best to allocate enough buffers so
that each connection can have as many as it wants.  You can limit how
many you need to allocate in total by only allowing each connection to
have a small TCP_WND (if you're using TCP that is, for UDP it is harder
to limit).

> Or do you see a better way?
> Maybe
> - loading lwIP completely twice ??

That would be the easiest way to get complete separation, although it
would only be easy if each process only wanted to use one of the netifs,
as I don't think you could map two copies of lwIP into a single process
and still be able to use them both.

> - defining a "watermark" / limit or something else for data port at 50%
> of pool buffer size to provoke that pool is "full" at this "line" ??

That would require writing some code, but would probably be the most
useful way, if you don't have the memory to just allocate enough buffers
to avoid this.  I would structure the watermark not as a limit on how
many can be used by each netif, but on how many can be used for received
packets, and how many can be used for sending packets as I think it is
these two paths that are actually probably in conflict: if you receive a
lot of data there might not be any packets left to send the
acknowledgement or reply until the application has dealt with them.  I'd
happily accept a patch that added this as I think it would be more
widely useful.  It is based on the premise that it's better to drop
received packets when you're under memory pressure (and rely on later
retransmissions) than accept those and limit your ability to send.

Kieran




reply via email to

[Prev in Thread] Current Thread [Next in Thread]