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

[Kieran Mansley]

On Mon, 2011-05-16 at 12:39 +0200, Thomas Richter (TCD - DE/Dresden)
wrote:
> > ... 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.

That is interesting: if you have worked out how many connections you
have, and multiplied that by the TCP_WND, and then ensured that there
are enough buffers to hold that much data, but you still see the
problem, then I would start debugging what the packets are being used
for when the problem occurs.  

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

That shouldn't matter: TCP does the retransmission for you.  The other
end would need no modification to use this strategy.

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

I haven't had a chance to look at the packet capture yet, so can't
answer this.

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

If you're using TCP then restricting the TCP_WND setting is the only
method you have to control the flow and buffer usage at the receiver.

Kieran