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

[Thomas Richter (TCD - DE/Dresden)]

> ... it might just be best to allocate enough buffers so
> that each connection can have as many as it wants. 

Sorry, this doesn't solve the problem. It will shift the problem to a
later time stamp or reduce the probability of occurrence.
The same behavior is with reduced size of TCP_WND.

> ...  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.

The option to drop the received packets if the buffer pool can not
handle new packet isn't option which I can use.
I can only work at one side of Ethernet communication. The other side is
fixed!

A question to my wireshark log:
What is the reason that after frame 101 the destination (IP:
192.168.1.100) do not handle incoming frames from source (IP: 192.168.1.1)?
Between Frames 87-101 all is working "fine".
The worst case occurs with frame 107 where the message at control port
(6500) gets no response (ACK).

In summary:
If I find a way to control the data stream with flow control mechanism
at data port then I would be happy.

Thomas


Am 16.05.2011 11:11, schrieb Kieran Mansley:
> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>