[lwip-users] Re: [lwip] ARP implementation

[Adam Dunkels]

Hi!

On Thursday 11 October 2001 09:28, you wrote:
> Hi,
> I checked your ARP code, its working.
> A had to fix a few minor errors:
> 1.) arp.c, function arp_init, initialization of arp_table doesn't work
> because IP_ADDR_ANY is a constant not IP number. I just threw out the code
> it worked any way.
> 2.) arp.c, function arp_arp_input:
>       in case1, buffer p has to be released (pbuf_free) if IP address in
> ARP request doesn't match our IP number
>             in case1, macro HTONS() is called, should be htons()
>       default case is missing, with releasing buffer p
> 2.) tapif.c, function tapif_irq_handler():
>       switch statement, case ETHERTYPE_ARP. After sending ARP reply
> (function tapif_lowlevel_output(), buffer p has to be released)
>       default case has to be added, with releasing buffer p

Thanks, those bugs are now fixed in the CVS version on the homepage.

Regarding bug #1, that has been fixed in the file 
src/include/ipv4/lwip/ip_addr.h instead. Even though the BSS segment (where 
the arp_table array is) should be initialized to zeroes, some compilers don't 
do this. It is therefore better to explicitly initialize such structures.

> I have a few questions:
> How did you test UDP protocol. Is there same UDP application included, I
> saw only udp_echo?

UDP has not been heavily tested - there are two applications that use UDP, 
udp_echo and proj/unixsim/apps/shell.c. The latter is a simple command line 
shell application that can do quite a lot of stuff. This application has been 
used for testing lwIP. 

> How to measure the performance?

How do you mean?

> About the driver:
> Current implementation uses only one thread (ethernet input). First I will
> do some performance measurement, and than maybe implement a second
> transmitting thread too. What do you suggest, is there a big difference in
> performance, between one and two thread version?

I guess this depends on how the network adapter is programmed. If the adapter 
can be programmed to buffer output packets and queue them, so that the 
transmission can be done quickly, there is no need to do it in a separate 
thread. If the transmission is slow (such as is would be over a slow serial 
line), there would be a gain since the TCP/IP thread quicker can go back to 
its processing.

> System architecture tests worked (mailboxes, semaphores, timers, threads).
> But I haven't yet run some bigger applications.
> Next I will try to reduce the stack's and driver's memory requirements.

You can try running shell.c and play around a little. It can be made to 
excercise most of lwIPs features.

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]