lwip-users
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]