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 _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users