[Top][All Lists]
[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: |
Thomas Richter (TCD - DE/Dresden) |
Subject: |
Re: [lwip-users] add 2 netif for 2 ETH MAC´s to have 2 buffer pools |
Date: |
Mon, 16 May 2011 12:39:02 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 |
> ... 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
>
>