This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: lwIP port status
- From: MaxiD <mx dot d at mail dot ru>
- To: ecos-devel at ecos dot sourceware dot org
- Date: Wed, 22 Jul 2009 03:31:36 -0700 (PDT)
- Subject: Re: lwIP port status
- References: <4A1173B6.5000805@intefo.ch>
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.