Re: lwIP port status

Simon Kallweit wrote:
> 
> Hi
> 
> It's time for a little status update on the lwIP 1.3.x port. Let me give 
> you a little list of what has been done lately:
> 
> * CDL should include every configuration option offered by lwIP now, was 
> reviewed by John Dallaway and got restructured and cleaned up afterwards.
> * Implemented 'Sequential' mode.
> * Updated to the latest lwIP sources from CVS again.
> * Reviewed test cases.
> * Cleanup, cleanup, cleanup.
> 
> What's left to do is lots of testing and writing documentation etc. I 
> think it would be great to finish the port when lwIP hits the 1.3.1 
> release which should not be too far from now. If time permits, I may 
> also work a bit on PPP.
> 
> For now I would like to shortly discuss my 'Sequential' implementation. 
> In 'Sequential' mode, lwIP is configured with NO_SYS == 0 and allows for 
> multiple threads to use the stack (netcomm, sockets). The main thread 
> (tcpip) is basically used to synchronize all threads accessing the stack 
> by sequentially processing incoming messages on a message queue. When a 
> packet arrives on an interface, a message pointing to the packet is sent 
> to the message queue. This is what is done with the SLIP interface for 
> example. SLIP is running in it's own thread, reading from the serial 
> device (blocked). When a packet is received, it is passed to the tcpip 
> thread by posting a message to the message queue. This way the packet is 
> processed in sync with the tcpip thread. For ethernet devices I choose 
> another path. The old port implemented a separate ethernet delivery 
> thread which would wait on a semaphore for packets to arrive. It would 
> wake up when a packet arrives and read it from the interface and send a 
> message to the tcpip thread. In my port I got rid of the delivery thread 
> and implemented sending/receiving as follows:
> 
> When a packet is sent, lwIP assumes that after the call to output the 
> packet, the packet is no longer access by the driver and can be 
> released. This means that the packet should be sent before the call 
> returns -> blocking, or packets would have to be copied and put in a 
> queue, which I think does not make much sense. I therefore implemented 
> sending to be blocking.
> 
> Receiving packets could be done in parallel to the tcpip thread, but 
> packets still have to be processed in sync to the tcpip thread. I choose 
> a really simple route. When a packet arrives, a callback is registered 
> with the tcpip thread, which is called back as soon as ongoing 
> processing in the tcpip thread is finished. The callback then reads all 
> the pending packets from the ethernet devices and directly processes them.
> 
> What do people think of this approach? Is it feasible or completely 
> broken? :)
> 
> Anybody cares to do some testing of the new lwIP port?
> 
> Simon
> 
> 

Hello Simon,

I get errors with mboxes with older versions so I would test your port.
Would you please send me the link to your port??

Thanks & best regards
Max
-- 
View this message in context: http://www.nabble.com/lwIP-port-status-tp23598717p24603788.html
Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.