lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] lwip-users Digest, Vol 187, Issue 3


From: Slava Zilberfayn
Subject: Re: [lwip-users] lwip-users Digest, Vol 187, Issue 3
Date: Mon, 4 Mar 2019 08:24:10 -0500

Hello Lwip-users-request,

After  spending  a  week  on  this  problem, studying how the
library works, I realized my problem was that netif_add() was
called   with   ethernet_input()  as a parameter,  instead  of
tcp_input(). Something I copied
from  some  sample  example and never really gave it a second
thought..

lurno> Message: 1
lurno> Date: Fri, 1 Mar 2019 20:05:19 -0500
lurno> From: Slava Zilberfayn <address@hidden>
lurno> To: address@hidden
lurno> Subject: Re: [lwip-users] lwIP trouble (tcp_write called from more
lurno>         than one location)
lurno> Message-ID: <address@hidden>
lurno> Content-Type: text/plain; charset="us-ascii"

lurno> Hello,

lurno> Hopefully  somebody  could  shed  some  light on the things I
lurno> observe.

lurno> I have

lurno> #define LWIP_TCPIP_CORE_LOCKING_INPUT 0
lurno> #define LWIP_TCPIP_CORE_LOCKING 0

lurno> but  when the RX thread receives the ACK in the middle
lurno> of   the   TCP/IP core   thread   serving  my  second netconn_write
lurno> (specifically  being  inside  tcp_write),  it (the rx-thread) ends up 
calling
lurno> tcp_write     itself.     My     understanding     is    that
lurno> LWIP_TCPIP_CORE_LOCKING_INPUT==0 should prevent the RX thread
lurno> from  trying to call  tcp_write directly. Am I wrong?
lurno> In this configuration ASSERT_CORE_LOCKED()  is empty and
lurno> does  not  do  anything,  so  that  seems  to  be  an invalid
lurno> situation.

lurno> Is  that  a  legal  scenario? Immediately thereafter
lurno> things blow up.

lurno> I have tried with
lurno> #define LWIP_TCPIP_CORE_LOCKING_INPUT 1
lurno> #define LWIP_TCPIP_CORE_LOCKING 1

lurno> in this case almost  exact  same thing happens, with minor difference 
that
lurno> the  first  tcp_write  is now called from the tcp_echo thread
lurno> (via netconn_write).

lurno> Looking  through  source code I see that TCP_EVENT_SENT macro
lurno> in  tcp_input()  is  dependent  upon LWIP_EVENT_API, which is
lurno> supposed  to  make  it  use  message  instead  of calling the
lurno> function directly. But when I enable LWIP_EVENT_API == 1 the code
lurno> does   not   build   at   all,   because   tcp_recv() used  in
lurno> api_msg.c:520(setup_tcp())  is  only  declared  in tcp.h when
lurno> LWIP_CALLBACK_API == 1.

lurno> Two  concurrent  calls  to  netconn_write  seems  to be wrong
lurno> situation, but I don't see what I do wrong here.

lurno> Thank you, Slava



lurno>> Message: 3
lurno>> Date: Tue, 26 Feb 2019 22:10:24 +0100
lurno>> From: Simon Goldschmidt <address@hidden>
lurno>> To: address@hidden
lurno>> Subject: Re: [lwip-users] lwIP trouble
lurno>> Message-ID: <address@hidden>
lurno>> Content-Type: text/plain; charset=utf-8; format=flowed


lurno>> On 26.02.2019 22:07, Slava Zilberfayn wrote:
>>> Hello all,
>>>
>>> I've  done some more testing with tcpecho example. When I set
>>> chunk  size  to  be  less  than the size of the tcpecho
>>> packets,  I  get  exactly  the same failure during the second
>>> call  to netconn_write. When the packet size small than chunk
>>> size  it  crashes fairly quickly. For example I set chunk size
>>> to  400  in the tcpecho example and send 400 bytes packets to
>>> it. Works fine.
>>>
>>> If   I  start  sending  401 bytes, it crashes fairly quickly.
>>> There   must   me   something  wrong  with  my  settings. Any
>>> help would be appreciated.


lurno>> If you could get this reproduced with minimal changes on the win32 or
lurno>> linux port, it would be *much* easier to see what's going on.


lurno>> Regards,

lurno>> Simon




lurno>> ------------------------------

lurno>> Message: 4
lurno>> Date: Tue, 26 Feb 2019 18:45:29 -0500
lurno>> From: Dave Nadler <address@hidden>
lurno>> To: Johan Borkhuis <address@hidden>,     Mailing list for lwIP
lurno>>         users <address@hidden>
lurno>> Subject: Re: [lwip-users] Throughput benchmark question - nasty pauses
lurno>> Message-ID: <address@hidden>
lurno>> Content-Type: text/plain; charset="utf-8"; Format="flowed"

lurno>> I figured out how to get the wireshark trace,
lurno>> but how to get the wireshark GUI to output the summary below in text
lurno>> baffles me, hope the pic is OK:
lurno>> Everything is going swimmingly until 4316.
lurno>> I don't understand the meaning of "previous segment not captured" here -
lurno>> something got dropped.
lurno>> And then it takes a second to get going again.
lurno>> Any pointers appreciated!
lurno>> Thanks,
lurno>> Best Regards, Dave

lurno>> On 2/20/2019 1:45 AM, Johan Borkhuis wrote:
>>> Dave,
>>>
>>> First thing would be to sniff the network using Wireshark, and see 
>>> what happens there when the traffic pauses.
>>> This would usually give a good indication on what did happen.
>>>
>>> Regards,
>>> Johan
>>>
>>> On 2019-02-20 00:15, Dave Nadler wrote:
>>>> Hi - Newbie here trying to do some basic throughput tests.
>>>> LwIP 2.1.2 on FreeRTOS 9, ST32F429, IPv4, TCP.
>>>>
>>>> I want to see how much I can consistently push through the stack.
>>>> Made a simple test server (sockets API) which repeatedly outputs
>>>> 101-character lines.
>>>> I access the server via PuTTY raw mode on Winbloze over a local
>>>> network.
>>>> I can usually send 3 lines per msec for a second (3000 lines in 1
>>>> second), but...
>>>> Sometimes, I get ~ 1-second pauses (as seen in Putty or TeraTerm).
>>>>
>>>> How should I go about understanding where the pauses come from?
>>>>
>>>> Thanks in advance for any hints,
>>>> Best Regards, Dave
>>>>
>>>> -- 
>>>> Dave Nadler, USA East Coast voice (978) 263-0097, address@hidden,
>>>> Skype
>>>> ?Dave.Nadler1
>>>> _______________________________________________
>>>> lwip-users mailing list
>>>> address@hidden
>>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>>
>>>



-- 
Slava Zilberfayn mailto:address@hidden
Phone: 416 7289367

Home Electronics, www.home-electro.com
100 Drumlin Circle,
Suite 205
Concord, ON, L4K 3E6
CANADA




reply via email to

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