[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:56:46 +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 |
> 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".
I have an idea why only 8 received packets (frames 86, 88, 90, 92, 94,
96, 98, 100) are handled by ACK:
In my used Ethernet device driver (TSE, see
http://lwip.wikia.com/wiki/Available_device_drivers) only 8 buffer are
allocated for Rx (called LWIP_RX_ETH_BUFFER * ethernetif->lwipRxPbuf[]).
Is it right?
If yes, then the basic problem is in my driver. Hmm...
Thomas
Am 16.05.2011 12:39, schrieb 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
>>
>>
--
Mit freundlichen Grüßen / Kind regards
Thomas Richter
.--------------------------------------------------.
! Teleconnect GmbH ! !
! Am Lehmberg 54 ! !
! 01157 Dresden ! Best view !
! Germany ! using !
! Phone: +49 351 4236 218 ! fixed font.!
! FAX: +49 351 4236 209 ! !
! Email: rict[at]teleconnect.de ! !
!--------------------------------------------------!
! Phone: +49 351 4236 210 (general) !
! http://www.teleconnect.de !
! !
! Handelsregister: Dresden HRB 1040 !
! USt.-IdNr.: DE140301522 !
! Geschäftsführer: Dr. Gerald Nürnberger !
! Dr. Andreas Bluschke !
! !
! Speicherung und Weitergabe der Adressdaten incl. !
! email- Adresse für Werbezwecke untersagt. !
! Use of address information and email address for !
! advertisement purposes is prohibited. !
.--------------------------------------------------.