lwip 1.3.1 testing

lwip 1.3.1 testing

[Simon Kallweit]

Hi

If anyone volunteers, I'd be glad if you could test the current state of 
the lwip 1.3.1 port. It has been updated with the latest changes from 
the 1.3.1 release. I currently left in my changes for SLIP and PPP (see 
my last mail for details), but this should not matter for testing. The 
package can be installed by just replacing the existing lwip and eth 
drivers packages.

http://download.westlicht.ch/lwip-20090821.tar.gz

Thanks
Simon

Re: lwip 1.3.1 testing

[John Dallaway]

Simon Kallweit wrote:

> If anyone volunteers, I'd be glad if you could test the current state of
> the lwip 1.3.1 port. It has been updated with the latest changes from
> the 1.3.1 release. I currently left in my changes for SLIP and PPP (see
> my last mail for details), but this should not matter for testing. The
> package can be installed by just replacing the existing lwip and eth
> drivers packages.
> 
> http://download.westlicht.ch/lwip-20090821.tar.gz

Testing on big-endian targets would be especially welcome.

John Dallaway

Re: lwip 1.3.1 testing

[Edgar Grimberg]

On Fri, Aug 21, 2009 at 9:42 AM, John Dallaway<john@dallaway.org.uk> wrote:
> Simon Kallweit wrote:
>
>> If anyone volunteers, I'd be glad if you could test the current state of
>> the lwip 1.3.1 port. It has been updated with the latest changes from
>> the 1.3.1 release. I currently left in my changes for SLIP and PPP (see
>> my last mail for details), but this should not matter for testing. The
>> package can be installed by just replacing the existing lwip and eth
>> drivers packages.
>>
>> http://download.westlicht.ch/lwip-20090821.tar.gz
>
> Testing on big-endian targets would be especially welcome.
>

I need to shape up the TSEC driver for MPC8313 and then I'll give it a
try. It will take some days, though..

Regards,
Edgar



-- 
Edgar Grimberg
System Developer
Zylin AS
ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html
Phone: (+47) 51 63 25 00

Re: lwip 1.3.1 testing

[Sergei Gavrikov]

On Fri, Aug 21, 2009 at 09:12:02AM +0200, Simon Kallweit wrote:
> Hi
>
> If anyone volunteers, I'd be glad if you could test the current state of  
> the lwip 1.3.1 port. It has been updated with the latest changes from  
> the 1.3.1 release. I currently left in my changes for SLIP and PPP (see  
> my last mail for details), but this should not matter for testing. The  
> package can be installed by just replacing the existing lwip and eth  
> drivers packages.
>
> http://download.westlicht.ch/lwip-20090821.tar.gz

Hi Simon,

I need a bit clarification from you. Does it mean that we should try
'lwip_eth' template only on real HW? I stub on 'left in' phrase. Did
your SLIP/PPP hack leave this tarball? Does it mean what tests of SLIP,
for example, will be useless just now?

And more, could you, please, post a reason ECM (the legal eCos minimal
configuration file for such a called 'Sequential' mode)? I hope you have
something for synthetic target, IMO, it would help to setup tests more
quickly, I see that real hardware will be to require the uploads and
debugging via serial (at the least for my target), because, I will need
to test the net tests. Well, that would be great and that will save a
time for "digging"/uploading.

If you did not save own ECM(s), the simplest question is, Did you use
DHCP or static IPs in your tests?

I'm going to try your lwip port on ARM-7 (LE) this weekend.

FYI: My first compile-stop did occur in simple.c, then I send a patch.

Thank you.

Sergei

> Thanks
> Simon

Re: lwip 1.3.1 testing

[Sergei Gavrikov]

[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]

On Fri, Aug 21, 2009 at 09:43:36PM +0300, Sergei Gavrikov wrote:
> On Fri, Aug 21, 2009 at 09:12:02AM +0200, Simon Kallweit wrote:
> > Hi
> >
> > If anyone volunteers, I'd be glad if you could test the current state of  
> > the lwip 1.3.1 port. It has been updated with the latest changes from  
> > the 1.3.1 release. I currently left in my changes for SLIP and PPP (see  
> > my last mail for details), but this should not matter for testing. The  
> > package can be installed by just replacing the existing lwip and eth  
> > drivers packages.
> >
> > http://download.westlicht.ch/lwip-20090821.tar.gz
> 
> Hi Simon,
> 
> I need a bit clarification from you. Does it mean that we should try
> 'lwip_eth' template only on real HW? I stub on 'left in' phrase. Did
> your SLIP/PPP hack leave this tarball? Does it mean what tests of SLIP,
> for example, will be useless just now?

Hi Simon,

Last weekend I tested a bit your lwip 1.3.1 port. Well, that was not any
stress test, just compile and run a few net tests out from the box and
pinging. Short summary the below

  Synth			  ARM-7 (LE)
+ http_simple		+ http_simple
+ http_sequential	+ http_sequntial
+ tcpecho		+ tcpecho

External ping/arping worked for both targets. For the tests I used
configs with DHCP support.

For the followers I attach the ecos minimal configs which I used for
simple and sequential modes for synth and real hardware and a small
patch for simple.c, sequential.c. All build were started as

ecosconfig new <target> lwip_eth

I had got `stack overlow' in GDB with default stack's settings on real
target when I enabled a tracing and turned off optimization, I tried
multipy stack amounts (for interrupts, tcp_thread, eth_thread) x 2, x 4,
but error did not go away.  Perhaps, I should investigate more time for
the issue, but may be in the next weekend.

Thanks for the port!

Regards
Sergei

Appendix

Host and tools details
----------------------
Host		Ubuntu 8.04.3 LTS
eCos		CVS updated + lwIP 1.3.1 package
ecosconfig	3.net (Aug 23 2009 17:00:44)
dhcpd3		V3.0.6

Synth target details
--------------------
GCC		4.2.4
GDB		GNU gdb 6.8-debian
CFLAGS		-g -O2

ARM target details
------------------
BOARD		Olimex LPC-E2294 rev. B
NIC		DAVICOM DM900 32-bits
STARTUP		RAM
ROM monitor	RedBoot+GDB stubs
GCC		arm-eabi-gcc 4.3.2
CFLAGS		-g -O2

[-- Attachment #2: lwip.patch --]
[-- Type: text/x-diff, Size: 1858 bytes --]

diff -r c04951f2b777 net/lwip_tcpip/current/src/ecos/sequential.c
--- a/net/lwip_tcpip/current/src/ecos/sequential.c	Fri Aug 21 20:43:16 2009 +0300
+++ b/net/lwip_tcpip/current/src/ecos/sequential.c	Mon Aug 24 17:27:13 2009 +0300
@@ -75,6 +75,10 @@
 #include <cyg/infra/diag.h>
 #include <cyg/kernel/kapi.h>
 
+#ifdef CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT
+#include <cyg/hal/hal_if.h>            // HAL_CTRLC_CHECK
+#endif
+
 #ifdef CYGPKG_LWIP_ETH
 #include <cyg/io/eth/eth_drv.h>
 #include <cyg/io/eth/netdev.h>
@@ -227,7 +231,7 @@
 #endif
                 sc->state &= ~ETH_DRV_NEEDS_DELIVERY;
 #if defined(CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT)
-                was_ctrlc_int = HAL_CTRLC_CHECK(*sc->funs->int_vector(sc),
+                was_ctrlc_int = HAL_CTRLC_CHECK(sc->funs->int_vector(sc),
                                                 (int) sc);
                 if (!was_ctrlc_int) // Fall through and run normal code
 #endif
diff -r c04951f2b777 net/lwip_tcpip/current/src/ecos/simple.c
--- a/net/lwip_tcpip/current/src/ecos/simple.c	Fri Aug 21 20:43:16 2009 +0300
+++ b/net/lwip_tcpip/current/src/ecos/simple.c	Mon Aug 24 17:27:13 2009 +0300
@@ -76,6 +76,10 @@
 #include <cyg/infra/diag.h>
 #include <cyg/kernel/kapi.h>
 
+#ifdef CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT
+#include <cyg/hal/hal_if.h>            // HAL_CTRLC_CHECK
+#endif
+
 #ifdef CYGPKG_LWIP_ETH
 #include <cyg/io/eth/eth_drv.h>
 #include <cyg/io/eth/netdev.h>
@@ -291,7 +295,7 @@
 #endif
                 sc->state &= ~ETH_DRV_NEEDS_DELIVERY;
 #if defined(CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT)
-                was_ctrlc_int = HAL_CTRLC_CHECK(*sc->funs->int_vector(sc),
+                was_ctrlc_int = HAL_CTRLC_CHECK(sc->funs->int_vector(sc),
                                                 (int) sc);
                 if (!was_ctrlc_int) // Fall through and run normal code
 #endif

[-- Attachment #3: synth_simple.ecm --]
[-- Type: text/plain, Size: 171 bytes --]

cdl_option CYGVAR_DEVS_ETH_ECOSYNTH_ETH0 {
    user_value 1
};
cdl_component CYGPKG_LWIP_DHCP {
    user_value 1
};
cdl_option CYGDAT_LWIP_ETH0_DHCP {
    user_value 1
};

[-- Attachment #4: synth_seq.ecm --]
[-- Type: text/plain, Size: 407 bytes --]

cdl_option CYGVAR_DEVS_ETH_ECOSYNTH_ETH0 {
    user_value 1
};
cdl_option CYGIMP_LWIP_MODE {
    user_value Sequential
};
cdl_component CYGPKG_LWIP_NETIF_API {
    user_value 1
};
cdl_component CYGPKG_LWIP_NETCONN_API {
    user_value 1
};
cdl_component CYGPKG_LWIP_SOCKET_API {
    user_value 1
};
cdl_component CYGPKG_LWIP_DHCP {
    user_value 1
};
cdl_option CYGDAT_LWIP_ETH0_DHCP {
    user_value 1
};

[-- Attachment #5: lpc_simple.ecm --]
[-- Type: text/plain, Size: 108 bytes --]

cdl_component CYGPKG_LWIP_DHCP {
    user_value 1
};
cdl_option CYGDAT_LWIP_ETH0_DHCP {
    user_value 1
};

[-- Attachment #6: lpc_seq.ecm --]
[-- Type: text/plain, Size: 344 bytes --]

cdl_option CYGIMP_LWIP_MODE {
    user_value Sequential
};
cdl_component CYGPKG_LWIP_NETIF_API {
    user_value 1
};
cdl_component CYGPKG_LWIP_NETCONN_API {
    user_value 1
};
cdl_component CYGPKG_LWIP_SOCKET_API {
    user_value 1
};
cdl_component CYGPKG_LWIP_DHCP {
    user_value 1
};
cdl_option CYGDAT_LWIP_ETH0_DHCP {
    user_value 1
};

Re: lwip 1.3.1 testing

[Simon Kallweit]

Sergei Gavrikov wrote:
> On Fri, Aug 21, 2009 at 09:43:36PM +0300, Sergei Gavrikov wrote:
>> On Fri, Aug 21, 2009 at 09:12:02AM +0200, Simon Kallweit wrote:
>>> Hi
>>>
>>> If anyone volunteers, I'd be glad if you could test the current state of  
>>> the lwip 1.3.1 port. It has been updated with the latest changes from  
>>> the 1.3.1 release. I currently left in my changes for SLIP and PPP (see  
>>> my last mail for details), but this should not matter for testing. The  
>>> package can be installed by just replacing the existing lwip and eth  
>>> drivers packages.
>>>
>>> http://download.westlicht.ch/lwip-20090821.tar.gz
>> Hi Simon,
>>
>> I need a bit clarification from you. Does it mean that we should try
>> 'lwip_eth' template only on real HW? I stub on 'left in' phrase. Did
>> your SLIP/PPP hack leave this tarball? Does it mean what tests of SLIP,
>> for example, will be useless just now?

Sorry for the late answer, have been busy. The current release does 
still include the SLIP/PPP hacks yes, I'll try to get at least the SLIP 
modifications into lwip before a proper release of my port. PPP will be 
mostly useless in it's current state, but it's probably better to leave 
it as it is in the current lwip release than having my hacks in.

> 
> Hi Simon,
> 
> Last weekend I tested a bit your lwip 1.3.1 port. Well, that was not any
> stress test, just compile and run a few net tests out from the box and
> pinging. Short summary the below
> 
>   Synth			  ARM-7 (LE)
> + http_simple		+ http_simple
> + http_sequential	+ http_sequntial
> + tcpecho		+ tcpecho

Very nice, for some 'stress testing' you can run nc_test_slave. You'll 
need the nc_test_master which can be found in 
packages/net/common/current/tests

> External ping/arping worked for both targets. For the tests I used
> configs with DHCP support.
> 
> For the followers I attach the ecos minimal configs which I used for
> simple and sequential modes for synth and real hardware and a small
> patch for simple.c, sequential.c. All build were started as
> 
> ecosconfig new <target> lwip_eth

The default lwip templates should probably be adapted to the new port. 
I'll look into that.

> I had got `stack overlow' in GDB with default stack's settings on real
> target when I enabled a tracing and turned off optimization, I tried
> multipy stack amounts (for interrupts, tcp_thread, eth_thread) x 2, x 4,
> but error did not go away.  Perhaps, I should investigate more time for
> the issue, but may be in the next weekend.

That sounds interesting. I have not seen anything like that on the synth 
target, but stacks are at least 16k each, so it's not a good comparison. 
I also use lwip+ppp on a STM32, have not had any problems there either, 
but I don't use ethernet there.

> Thanks for the port!

Thanks a lot for testing!!

Simon

lwip 1.3.1 testing

[Simon Kallweit]

[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

Hi

I have done a new lwip test release with the following changes:

* incorporated Sergei's patch (ctrl-c support)
* added an lwip_eth_simple and lwip_eth_sequential template

The new test release can be downloaded from 
http://download.westlicht.ch/lwip-20090825.tar.gz

To do synth tests do the following:

create a new configuration:
 > ecosconfig new linux lwip_eth_simple
or:
 > ecosconfig new linux lwip_eth_sequential

enable eth0 synth device (file is attached):
 > ecosconfig import eth_synth.ecm

build:
 > make
 > make -C build/net/lwip_tcpip/current tests

run tests (a sample target.tdf is attached):
./build/install/tests/net/lwip_tcpip/current/tests/httpd_simple -t 
target.tdf -io -nw

The current templates use DHCP to get an IP address. Just reconfigure 
for static IPs.

To do some stress testing you can run the nc_test_slave testcase (only 
available in sequential mode). You will need the corresponding master 
test, which can be found in the ecos repository under

packages/net/common/current/tests

To build the nc_test_master go to the upper directory and type:
 > make -f make.host

Also you should loosen up the very conservative default configuration of 
lwip pbufs to avoid dropped packets:

 > ecosconfig import pbufs.ecm
 > make && make -C build/net/lwip_tcpip/current tests



Testing on real hardware would be especially useful. Also testing on 
big-endian targets might reveal some issues, as I've only been testing 
on little-endian platforms.

Thanks a lot for testing!

Simon

[-- Attachment #2: eth_synth.ecm --]
[-- Type: text/plain, Size: 63 bytes --]

cdl_option CYGVAR_DEVS_ETH_ECOSYNTH_ETH0 {
    user_value 1
};

[-- Attachment #3: target.tdf --]
[-- Type: text/plain, Size: 61 bytes --]

synth_device ethernet {

    eth0 real eth1
    logging 0

}

[-- Attachment #4: pbufs.ecm --]
[-- Type: text/plain, Size: 118 bytes --]

cdl_option CYGNUM_LWIP_TCP_MSS {
    user_value 512
};

cdl_option CYGNUM_LWIP_PBUF_POOL_SIZE {
    user_value 64
};

Re: lwip 1.3.1 testing

[Sergei Gavrikov]

On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote:
> Hi
>
> I have done a new lwip test release with the following changes:
>
> * incorporated Sergei's patch (ctrl-c support)
> * added an lwip_eth_simple and lwip_eth_sequential template
>
> The new test release can be downloaded from  
> http://download.westlicht.ch/lwip-20090825.tar.gz

[snip]

> Testing on real hardware would be especially useful. Also testing on  
> big-endian targets might reveal some issues, as I've only been testing  
> on little-endian platforms.

Hi

Simon, I'll retest new package ASAP. And it seems for me that you would
get more volunteers if you will announce your nowadays work with those
minimal setup instructions on the ecos-discuss list too. Thanks for a
tip about the host's side setup for nc test, I will try it too.

Sergei

Re: lwip 1.3.1 testing

[Sergei Gavrikov]

On Tue, Aug 25, 2009 at 03:08:20PM +0300, Sergei Gavrikov wrote:
> On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote:
> > Hi
> >
> > I have done a new lwip test release with the following changes:
> >
> > * incorporated Sergei's patch (ctrl-c support)
> > * added an lwip_eth_simple and lwip_eth_sequential template
> >
> > The new test release can be downloaded from  
> > http://download.westlicht.ch/lwip-20090825.tar.gz
> 
> [snip]
> 
> > Testing on real hardware would be especially useful. Also testing on  
> > big-endian targets might reveal some issues, as I've only been testing  
> > on little-endian platforms.
> 
> Hi
> 
> Simon, I'll retest new package ASAP. And it seems for me that you would
> get more volunteers if you will announce your nowadays work with those
> minimal setup instructions on the ecos-discuss list too. Thanks for a
> tip about the host's side setup for nc test, I will try it too.

I retried nc master/slave test with your template and suggested pbuf
values. For synthetic (I used tap interface) I got good results with
lwIP, but, for real target, nc test passed for 100% master load and no
load of slave side only. I got about 2Mbits per second with the DM900
Ethernet driver (that driver is too slow, it uses memcpy() on every 4
bytes arrived or sent), and my board gives only about 15 VAX Mips for
RAM startup, and it seemed for me that was normal result.

For small TCP packets ("y\n"), I had got good results

yes | socat - tcp4:<board_ip>:7 ;# some stress tcp stream

"tcpecho" test did return "y" very long time, until I did break pipe
(^C).

Unfortunately, I could not manage "udpecho" using socat as above neither
for synthetic nor real hardware. So, my today score for lwIP 1.3.1 is

+ http_simple
+ http_sequential
+ ns_slave_test
+ tcpecho
- udpecho

What was your way to test "udpecho"?

Thanks, regards,

Sergei

Re: lwip 1.3.1 testing

[Simon Kallweit]

Sergei Gavrikov wrote:
> On Tue, Aug 25, 2009 at 03:08:20PM +0300, Sergei Gavrikov wrote:
>> On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote:
>>> Hi
>>>
>>> I have done a new lwip test release with the following changes:
>>>
>>> * incorporated Sergei's patch (ctrl-c support)
>>> * added an lwip_eth_simple and lwip_eth_sequential template
>>>
>>> The new test release can be downloaded from  
>>> http://download.westlicht.ch/lwip-20090825.tar.gz
>> [snip]
>>
>>> Testing on real hardware would be especially useful. Also testing on  
>>> big-endian targets might reveal some issues, as I've only been testing  
>>> on little-endian platforms.
>> Hi
>>
>> Simon, I'll retest new package ASAP. And it seems for me that you would
>> get more volunteers if you will announce your nowadays work with those
>> minimal setup instructions on the ecos-discuss list too. Thanks for a
>> tip about the host's side setup for nc test, I will try it too.
> 
> I retried nc master/slave test with your template and suggested pbuf
> values. For synthetic (I used tap interface) I got good results with
> lwIP, but, for real target, nc test passed for 100% master load and no
> load of slave side only. I got about 2Mbits per second with the DM900
> Ethernet driver (that driver is too slow, it uses memcpy() on every 4
> bytes arrived or sent), and my board gives only about 15 VAX Mips for
> RAM startup, and it seemed for me that was normal result.

Did you use the old lwip port on that board too? Did you get similar 
results in performance?

> For small TCP packets ("y\n"), I had got good results
> 
> yes | socat - tcp4:<board_ip>:7 ;# some stress tcp stream
> 
> "tcpecho" test did return "y" very long time, until I did break pipe
> (^C).
> 
> Unfortunately, I could not manage "udpecho" using socat as above neither
> for synthetic nor real hardware. So, my today score for lwIP 1.3.1 is
> 
> + http_simple
> + http_sequential
> + ns_slave_test
> + tcpecho
> - udpecho
> 
> What was your way to test "udpecho"?

I used nc (netcat) to send/receive UDP packets. But I did no stress 
testing with tcpecho, udpecho.

Simon

Re: lwip 1.3.1 testing

[Sergei Gavrikov]

On Wed, Aug 26, 2009 at 08:38:42AM +0200, Simon Kallweit wrote:
> Sergei Gavrikov wrote:
>> I retried nc master/slave test with your template and suggested pbuf
>> values. For synthetic (I used tap interface) I got good results with
>> lwIP, but, for real target, nc test passed for 100% master load and no
>> load of slave side only. I got about 2Mbits per second with the DM900
>> Ethernet driver (that driver is too slow, it uses memcpy() on every 4
>> bytes arrived or sent), and my board gives only about 15 VAX Mips for
                                                         ^^^^^^^^^^^
I checked, I got 11 Mips on the board.

>> RAM startup, and it seemed for me that was normal result.
>
> Did you use the old lwip port on that board too? Did you get similar  
> results in performance?

Unfortunately, it is not possible run old nc_test_slave from the box,
because it depends on SO_REUSE, and we cannot manage SO_REUSE from CDL,
more that, if we force it, we'll get error

include/lwip/opt.h:353

Well, I forced SO_REUSE=1 and built the test. I did not noticed that I
got more Mbits with old lwip. The packets out of sequence often, but, at
the least the slave side was responsible with a loading.

FYI

old "udpecho" is responsible on

(while : ; do echo `date`; sleep 1; done)|nc -u -4 <board_ip> 7

and

(while : ; do echo `date`; sleep 1; done)|socat - udp4:<board_ip>:7

but could not manage stress "yes|".

old "tcpecho" could answer on stress "yes".

Simon, thanks for the feedback and the port. It will be interesting to
know other results from other sources (hardware).

Regards,
Sergei

Re: lwip 1.3.1 testing

[Sergei Gavrikov]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

On Wed, Aug 26, 2009 at 08:38:42AM +0200, Simon Kallweit wrote:
> Sergei Gavrikov wrote:
>> On Tue, Aug 25, 2009 at 03:08:20PM +0300, Sergei Gavrikov wrote:
>>> On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote:
>>>> Hi
>>>>
>>>> I have done a new lwip test release with the following changes:
>>>>
>>>> * incorporated Sergei's patch (ctrl-c support)
>>>> * added an lwip_eth_simple and lwip_eth_sequential template
>>>>
>>>> The new test release can be downloaded from   
>>>> http://download.westlicht.ch/lwip-20090825.tar.gz

Hi

Simon, ya 2 cents. I found that the eth_tread's stack size is redefined
in sequential.c:101. First, that stack size is defined in the package's
header via CDL option. It seems the redefinition in sequetial.c can be
quite removed, otherwise the CDL value (eth stack size) wont be applied.

Sergei

[-- Attachment #2: sequential.c.patch --]
[-- Type: text/x-diff, Size: 481 bytes --]

diff -r bed5605f7e6d net/lwip_tcpip/current/src/ecos/sequential.c
--- a/net/lwip_tcpip/current/src/ecos/sequential.c	Tue Aug 25 18:32:48 2009 +0300
+++ b/net/lwip_tcpip/current/src/ecos/sequential.c	Wed Aug 26 23:28:54 2009 +0300
@@ -98,8 +98,6 @@
 CYG_HAL_TABLE_BEGIN(__NETDEVTAB__, netdev);
 CYG_HAL_TABLE_END(__NETDEVTAB_END__, netdev);
 
-#define ETH_THREAD_STACK_SIZE CYGNUM_HAL_STACK_SIZE_TYPICAL
-
 static sys_thread_t eth_thread_handle;
 static cyg_sem_t eth_thread_sem;
 

Re: lwip 1.3.1 testing

[Simon Kallweit]

Sergei Gavrikov wrote:
> On Wed, Aug 26, 2009 at 08:38:42AM +0200, Simon Kallweit wrote:
>> Sergei Gavrikov wrote:
>>> On Tue, Aug 25, 2009 at 03:08:20PM +0300, Sergei Gavrikov wrote:
>>>> On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote:
>>>>> Hi
>>>>>
>>>>> I have done a new lwip test release with the following changes:
>>>>>
>>>>> * incorporated Sergei's patch (ctrl-c support)
>>>>> * added an lwip_eth_simple and lwip_eth_sequential template
>>>>>
>>>>> The new test release can be downloaded from   
>>>>> http://download.westlicht.ch/lwip-20090825.tar.gz
> 
> Hi
> 
> Simon, ya 2 cents. I found that the eth_tread's stack size is redefined
> in sequential.c:101. First, that stack size is defined in the package's
> header via CDL option. It seems the redefinition in sequetial.c can be
> quite removed, otherwise the CDL value (eth stack size) wont be applied.

That was some left-over. The real define is ETH_THREAD_STACKSIZE not 
ETH_THREAD_STACK_SIZE. So it actually did not have any effect. Thanks 
for the hint!

In the meantime I have successfully committed my SLIP polling support to 
the lwip CVS, so it will be included in 1.4. I have also updated my port 
with these now official changes and did some testing. The new release:

http://download.westlicht.ch/lwip-20090827.tar.gz

Now I need to sort out PPP.

Simon

Re: lwip 1.3.1 testing

[Sergei Gavrikov]

On Thu, Aug 27, 2009 at 09:18:23AM +0200, Simon Kallweit wrote:
> In the meantime I have successfully committed my SLIP polling support to  
> the lwip CVS, so it will be included in 1.4. I have also updated my port  
> with these now official changes and did some testing. The new release:
>
> http://download.westlicht.ch/lwip-20090827.tar.gz

Thank you! I will try SLIP tonight on my target.

Sergei

>
> Now I need to sort out PPP.
>
> Simon
>
>

Re: lwip 1.3.1 testing

[John Dallaway]

Hi Simon

Simon Kallweit wrote:

> Testing on real hardware would be especially useful. Also testing on
> big-endian targets might reveal some issues, as I've only been testing
> on little-endian platforms.

Using your sources from lwip-20090827.tar.gz, I was able to build and
run the httpd_simple test on a PowerPC (big-endian) target OK. DHCP over
ethernet was also OK.

The lwIP CDL script currently builds ecos/sio.c unconditionally so
CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled.
It would be good to compile ecos/sio.c via a CDL option which is
"calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source
code will permit this.

Some other source code files which look like they might benefit from
conditional compilation:

    ecos/ppp.c ecos/sequential.c ecos/simple.c netif/slipif.c

How is you own testing of lwIP 1.3.1 progressing?

John Dallaway

Re: lwip 1.3.1 testing

[Simon Kallweit]

John Dallaway wrote:
> Hi Simon
> 
> Simon Kallweit wrote:
> 
>> Testing on real hardware would be especially useful. Also testing on
>> big-endian targets might reveal some issues, as I've only been testing
>> on little-endian platforms.
> 
> Using your sources from lwip-20090827.tar.gz, I was able to build and
> run the httpd_simple test on a PowerPC (big-endian) target OK. DHCP over
> ethernet was also OK.

That's good to hear.

> The lwIP CDL script currently builds ecos/sio.c unconditionally so
> CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled.
> It would be good to compile ecos/sio.c via a CDL option which is
> "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source
> code will permit this.

sio.c is always compiled, but there is an #ifdef which includes the code 
only when either CYGPKG_LWIP_SLIP or CYGFUN_LWIP_PPPOS_SUPPORT is 
active. Also, CYGPKG_IO_SERIAL_DEVICES is only enabled if either SLIP or 
PPPoS support is enabled. Do you think solving that dependency in CDL is 
the better approach?

> Some other source code files which look like they might benefit from
> conditional compilation:
> 
>     ecos/ppp.c ecos/sequential.c ecos/simple.c netif/slipif.c

Same principles apply here.

> How is you own testing of lwIP 1.3.1 progressing?

Well, I'm currently using devices with lwIP 1.3.1 in field tests. They 
run in the 'simple' mode (single-threaded) and use PPP for GPRS 
connections via a GSM modem. I have not seen any issues with the current 
port. The devices run for days until they may be power-cycled for 
updates or maintenance.

Application development is done on the synthetic target, using a 
simulated GSM modem, simulating GPRS connections by spawning a local PPP 
server. No issues have occurred with this configuration either, although 
runtimes are usually only minutes to hours.

Simon

Re: lwip 1.3.1 testing

[John Dallaway]

Hi Simon

Simon Kallweit wrote:

>> The lwIP CDL script currently builds ecos/sio.c unconditionally so
>> CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled.
>> It would be good to compile ecos/sio.c via a CDL option which is
>> "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source
>> code will permit this.
> 
> sio.c is always compiled, but there is an #ifdef which includes the code
> only when either CYGPKG_LWIP_SLIP or CYGFUN_LWIP_PPPOS_SUPPORT is
> active. Also, CYGPKG_IO_SERIAL_DEVICES is only enabled if either SLIP or
> PPPoS support is enabled. Do you think solving that dependency in CDL is
> the better approach?

OK, it seems that this issue has already been resolved. I was looking at
a slightly older revision of sio.c. As a general rule, it's preferable
to compile only those source code files which are needed. Clearly the
most important thing is to ensure that the resulting binaries are not
bloated with unused code/data.

>> How is you own testing of lwIP 1.3.1 progressing?
> 
> Well, I'm currently using devices with lwIP 1.3.1 in field tests. They
> run in the 'simple' mode (single-threaded) and use PPP for GPRS
> connections via a GSM modem. I have not seen any issues with the current
> port. The devices run for days until they may be power-cycled for
> updates or maintenance.
> 
> Application development is done on the synthetic target, using a
> simulated GSM modem, simulating GPRS connections by spawning a local PPP
> server. No issues have occurred with this configuration either, although
> runtimes are usually only minutes to hours.

So I think we should roll this out to eCos CVS soon. This will help with
further testing coverage.

One minor point: It would be very useful for the stack to report its own
IP address on the diagnostic channel.

John Dallaway

Re: lwip 1.3.1 testing

[Simon Kallweit]

John Dallaway wrote:
> Hi Simon
> 
> Simon Kallweit wrote:
> 
>>> The lwIP CDL script currently builds ecos/sio.c unconditionally so
>>> CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled.
>>> It would be good to compile ecos/sio.c via a CDL option which is
>>> "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source
>>> code will permit this.
>> sio.c is always compiled, but there is an #ifdef which includes the code
>> only when either CYGPKG_LWIP_SLIP or CYGFUN_LWIP_PPPOS_SUPPORT is
>> active. Also, CYGPKG_IO_SERIAL_DEVICES is only enabled if either SLIP or
>> PPPoS support is enabled. Do you think solving that dependency in CDL is
>> the better approach?
> 
> OK, it seems that this issue has already been resolved. I was looking at
> a slightly older revision of sio.c. As a general rule, it's preferable
> to compile only those source code files which are needed. Clearly the
> most important thing is to ensure that the resulting binaries are not
> bloated with unused code/data.

I can still change that. I just wonder what's the best approach here. 
Currently there is an option CYGIMP_LWIP_MODE which lets the user select 
"Simple" or "Sequential" mode. Should I remove this option in favor of 
two mutually exclusive components so I can only compile the simple.c or 
sequential.c? I can also create two pseudo components which are 
calculated by CYGIMP_LWIP_MODE == "Simple/Sequential" to compile the 
respective file, but this will introduce bloat in the configuration tool.

The same applies to sio. I can add a new package CYGPKG_LWIP_SIO which 
is required by both PPPoS and SLIPIF. I think the best place would be 
the "APIs" section as the SIO may be also used for other purposes than 
lwIP's internal. So a user could enable sio without using SLIPIF or PPPoS.

What do you think?

>>> How is you own testing of lwIP 1.3.1 progressing?
>> Well, I'm currently using devices with lwIP 1.3.1 in field tests. They
>> run in the 'simple' mode (single-threaded) and use PPP for GPRS
>> connections via a GSM modem. I have not seen any issues with the current
>> port. The devices run for days until they may be power-cycled for
>> updates or maintenance.
>>
>> Application development is done on the synthetic target, using a
>> simulated GSM modem, simulating GPRS connections by spawning a local PPP
>> server. No issues have occurred with this configuration either, although
>> runtimes are usually only minutes to hours.
> 
> So I think we should roll this out to eCos CVS soon. This will help with
> further testing coverage.

There is still one area which needs cleanup, PPP :/ I'm still not sure 
what we're going to do with that. I need single-thread support for PPP 
in my applications, but unfortunately this breaks multi-thread support 
and adds code changes which are not currently in the lwIP tree. Best 
would be to go with the current lwIP code, but this is also broken in 
places! And I currently don't have much time to sort this out properly.

> One minor point: It would be very useful for the stack to report its own
> IP address on the diagnostic channel.

I'll try to implement this. I guess you're mainly talking about DHCP IPs 
right?

Simon

Re: lwip 1.3.1 testing

[John Dallaway]

Hi Simon

Simon Kallweit wrote:

> John Dallaway wrote:
>> Hi Simon
>>
>> Simon Kallweit wrote:
>>
>>>> The lwIP CDL script currently builds ecos/sio.c unconditionally so
>>>> CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled.
>>>> It would be good to compile ecos/sio.c via a CDL option which is
>>>> "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source
>>>> code will permit this.
>>> 
>>> sio.c is always compiled, but there is an #ifdef which includes the code
>>> only when either CYGPKG_LWIP_SLIP or CYGFUN_LWIP_PPPOS_SUPPORT is
>>> active. Also, CYGPKG_IO_SERIAL_DEVICES is only enabled if either SLIP or
>>> PPPoS support is enabled. Do you think solving that dependency in CDL is
>>> the better approach?
>>
>> OK, it seems that this issue has already been resolved. I was looking at
>> a slightly older revision of sio.c. As a general rule, it's preferable
>> to compile only those source code files which are needed. Clearly the
>> most important thing is to ensure that the resulting binaries are not
>> bloated with unused code/data.
> 
> I can still change that. I just wonder what's the best approach here.
> Currently there is an option CYGIMP_LWIP_MODE which lets the user select
> "Simple" or "Sequential" mode. Should I remove this option in favor of
> two mutually exclusive components so I can only compile the simple.c or
> sequential.c? I can also create two pseudo components which are
> calculated by CYGIMP_LWIP_MODE == "Simple/Sequential" to compile the
> respective file, but this will introduce bloat in the configuration tool.

I would recommend a "radio button" approach for mutually exclusive modes
which have associated source files. Something like:

  cdl_interface CYGINT_LWIP_MODES {
    display "Enabled lwIP modes"
    no_define
    requires 1 == CYGINT_LWIP_MODES
    description "This interface is used to force mutually exclusive
      selection of the available lwIP modes."
  }
  cdl_option CYGFUN_LWIP_MODE_SIMPLE {
    display "Simple mode"
    implements CYGINT_LWIP_MODES
    compile ecos/simple.c
  }
  cdl_option CYGFUN_LWIP_MODE_SEQUENTIAL {
    display "Sequential mode"
    implements CYGINT_LWIP_MODES
    compile ecos/sequential.c
  }

> The same applies to sio. I can add a new package CYGPKG_LWIP_SIO which
> is required by both PPPoS and SLIPIF. I think the best place would be
> the "APIs" section as the SIO may be also used for other purposes than
> lwIP's internal. So a user could enable sio without using SLIPIF or PPPoS.

It would be best to use another CDL interface to enable compilation of
this code. Something like:

  cdl_interface CYGINT_LWIP_SIO_REQUIRED {
    no_define
    display "Items requiring lwIP serial operations"
    description "Items requiring use of the lwIP serial operations code
      should implement this interface."
  }
  cdl_option CYGFUN_LWIP_SIO {
    display "Serial operations support"
    calculated { CYGINT_LWIP_SIO_REQUIRED > 0 }
    compile ecos/sio.c
  }
  cdl_component CYGPKG_LWIP_SLIP {
    implements CYGINT_LWIP_SIO_REQUIRED
    compile ...
    ...
  }
  cdl_component CYGPKG_LWIP_PPP {
    implements CYGINT_LWIP_SIO_REQUIRED
    compile ...
    ...
  }

This is a little more complicated than a simple "requires
CYGFUN_LWIP_SIO" but ensures that CYGFUN_LWIP_SIO becomes disabled when
the number of components requiring it falls to zero.

>>>> How is you own testing of lwIP 1.3.1 progressing?
>>> Well, I'm currently using devices with lwIP 1.3.1 in field tests. They
>>> run in the 'simple' mode (single-threaded) and use PPP for GPRS
>>> connections via a GSM modem. I have not seen any issues with the current
>>> port. The devices run for days until they may be power-cycled for
>>> updates or maintenance.
>>>
>>> Application development is done on the synthetic target, using a
>>> simulated GSM modem, simulating GPRS connections by spawning a local PPP
>>> server. No issues have occurred with this configuration either, although
>>> runtimes are usually only minutes to hours.
>>
>> So I think we should roll this out to eCos CVS soon. This will help with
>> further testing coverage.
> 
> There is still one area which needs cleanup, PPP :/ I'm still not sure
> what we're going to do with that. I need single-thread support for PPP
> in my applications, but unfortunately this breaks multi-thread support
> and adds code changes which are not currently in the lwIP tree. Best
> would be to go with the current lwIP code, but this is also broken in
> places! And I currently don't have much time to sort this out properly.

I thought we had concluded that we should treat lwIP PPP as a separate
project which would require liaison with the upstream lwIP
maintainer(s). Is there anyone else in the eCos community who is able
and willing to work on this?

>> One minor point: It would be very useful for the stack to report its own
>> IP address on the diagnostic channel.
> 
> I'll try to implement this. I guess you're mainly talking about DHCP IPs
> right?

Yes, although it might sometimes also be helpful to confirm a static IP
address.

John Dallaway

Re: lwip 1.3.1 testing

[Simon Kallweit]

John Dallaway wrote:
> I would recommend a "radio button" approach for mutually exclusive modes
> which have associated source files. Something like:
> 
>   cdl_interface CYGINT_LWIP_MODES {
>     display "Enabled lwIP modes"
>     no_define
>     requires 1 == CYGINT_LWIP_MODES
>     description "This interface is used to force mutually exclusive
>       selection of the available lwIP modes."
>   }
>   cdl_option CYGFUN_LWIP_MODE_SIMPLE {
>     display "Simple mode"
>     implements CYGINT_LWIP_MODES
>     compile ecos/simple.c
>   }
>   cdl_option CYGFUN_LWIP_MODE_SEQUENTIAL {
>     display "Sequential mode"
>     implements CYGINT_LWIP_MODES
>     compile ecos/sequential.c
>   }
> 
>> The same applies to sio. I can add a new package CYGPKG_LWIP_SIO which
>> is required by both PPPoS and SLIPIF. I think the best place would be
>> the "APIs" section as the SIO may be also used for other purposes than
>> lwIP's internal. So a user could enable sio without using SLIPIF or PPPoS.
> 
> It would be best to use another CDL interface to enable compilation of
> this code. Something like:
> 
>   cdl_interface CYGINT_LWIP_SIO_REQUIRED {
>     no_define
>     display "Items requiring lwIP serial operations"
>     description "Items requiring use of the lwIP serial operations code
>       should implement this interface."
>   }
>   cdl_option CYGFUN_LWIP_SIO {
>     display "Serial operations support"
>     calculated { CYGINT_LWIP_SIO_REQUIRED > 0 }
>     compile ecos/sio.c
>   }
>   cdl_component CYGPKG_LWIP_SLIP {
>     implements CYGINT_LWIP_SIO_REQUIRED
>     compile ...
>     ...
>   }
>   cdl_component CYGPKG_LWIP_PPP {
>     implements CYGINT_LWIP_SIO_REQUIRED
>     compile ...
>     ...
>   }
> 
> This is a little more complicated than a simple "requires
> CYGFUN_LWIP_SIO" but ensures that CYGFUN_LWIP_SIO becomes disabled when
> the number of components requiring it falls to zero.

I have adapted to CDL to reflect your recommendations. The new version 
can be fetched from

http://download.westlicht.ch/lwip-20091027.tar.gz

> I thought we had concluded that we should treat lwIP PPP as a separate
> project which would require liaison with the upstream lwIP
> maintainer(s). Is there anyone else in the eCos community who is able
> and willing to work on this?

True. I just wanted to point out that in it's current state PPP can only 
be used with simple mode.

>>> One minor point: It would be very useful for the stack to report its own
>>> IP address on the diagnostic channel.
>> I'll try to implement this. I guess you're mainly talking about DHCP IPs
>> right?
> 
> Yes, although it might sometimes also be helpful to confirm a static IP
> address.

I have implemented reporting of the netif configuration for both static 
configuration and DHCP on the interfaces loopif, slipif and eth. This is 
configurable by CYGFUN_LWIP_SHOW_NETIF_CONFIG which is now enabled by 
default.

Simon

Re: lwip 1.3.1 testing

[John Dallaway]

Hi Simon

Simon Kallweit wrote:

>>>> One minor point: It would be very useful for the stack to report its
>>>> own IP address on the diagnostic channel.
>>> 
>>> I'll try to implement this. I guess you're mainly talking about DHCP IPs
>>> right?
>>
>> Yes, although it might sometimes also be helpful to confirm a static IP
>> address.
> 
> I have implemented reporting of the netif configuration for both static
> configuration and DHCP on the interfaces loopif, slipif and eth. This is
> configurable by CYGFUN_LWIP_SHOW_NETIF_CONFIG which is now enabled by
> default.

Excellent. I would like to push through with final review and get your
lwIP port checked in to CVS, replacing the existing lwIP 1.1.1 port. Is
lwip-20091027.tar.gz still current or do you have further changes?
Should I be comparing your package with the upstream lwIP 1.3.1 sources
or is it now closer to lwIP 1.3.2 RC1?

John Dallaway
eCos maintainer

Re: lwip 1.3.1 testing

[Simon Kallweit]

John Dallaway wrote:
> Hi Simon
> 
> Simon Kallweit wrote:
> 
>>>>> One minor point: It would be very useful for the stack to report its
>>>>> own IP address on the diagnostic channel.
>>>> I'll try to implement this. I guess you're mainly talking about DHCP IPs
>>>> right?
>>> Yes, although it might sometimes also be helpful to confirm a static IP
>>> address.
>> I have implemented reporting of the netif configuration for both static
>> configuration and DHCP on the interfaces loopif, slipif and eth. This is
>> configurable by CYGFUN_LWIP_SHOW_NETIF_CONFIG which is now enabled by
>> default.
> 
> Excellent. I would like to push through with final review and get your
> lwIP port checked in to CVS, replacing the existing lwIP 1.1.1 port. Is
> lwip-20091027.tar.gz still current or do you have further changes?
> Should I be comparing your package with the upstream lwIP 1.3.1 sources
> or is it now closer to lwIP 1.3.2 RC1?

Sorry for the late answer, I have been on holidays. I think we should 
wait a few days for the lwIP 1.3.2 release. I'll merge the changes and 
do a few tests so we have a good initial version for a CVS checkin. It 
seems that some work has been done on the PPP code as well. I'll see how 
it fits with my current port.

Simon

Re: lwip 1.3.1 testing

[John Dallaway]

Hi Simon

Simon Kallweit wrote:

> John Dallaway wrote:
> 
>> Excellent. I would like to push through with final review and get your
>> lwIP port checked in to CVS, replacing the existing lwIP 1.1.1 port. Is
>> lwip-20091027.tar.gz still current or do you have further changes?
>> Should I be comparing your package with the upstream lwIP 1.3.1 sources
>> or is it now closer to lwIP 1.3.2 RC1?
> 
> Sorry for the late answer, I have been on holidays. I think we should
> wait a few days for the lwIP 1.3.2 release. I'll merge the changes and
> do a few tests so we have a good initial version for a CVS checkin. It
> seems that some work has been done on the PPP code as well. I'll see how
> it fits with my current port.

Great. It looks like lwIP 1.3.2 final will be released very soon now.

John Dallaway
eCos maintainer

Re: lwip 1.3.1 testing

[John Dallaway]

Hi Simon

Simon Kallweit wrote:

> John Dallaway wrote:
> 
>> Excellent. I would like to push through with final review and get your
>> lwIP port checked in to CVS, replacing the existing lwIP 1.1.1 port. Is
>> lwip-20091027.tar.gz still current or do you have further changes?
>> Should I be comparing your package with the upstream lwIP 1.3.1 sources
>> or is it now closer to lwIP 1.3.2 RC1?
> 
> Sorry for the late answer, I have been on holidays. I think we should
> wait a few days for the lwIP 1.3.2 release. I'll merge the changes and
> do a few tests so we have a good initial version for a CVS checkin. It
> seems that some work has been done on the PPP code as well. I'll see how
> it fits with my current port.

I've just noticed a new tarball lwip-20091224.tar.gz on your site. Were
you intending to do any further work on this in the immediate future or
shall we work towards an initial check-in of your port based on this
tarball?

John Dallaway
eCos maintainer