From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3189 invoked by alias); 18 May 2009 14:41:56 -0000 Received: (qmail 3181 invoked by uid 22791); 18 May 2009 14:41:55 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail05.solnet.ch (HELO mail05.solnet.ch) (212.101.4.139) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 May 2009 14:41:48 +0000 Received: from mail05.solnet.ch ([127.0.0.1]) by localhost (mail05.solnet.ch [127.0.0.1]) (SolNet-Check, port 10024) with LMTP id QUccSJc0ZBFp for ; Mon, 18 May 2009 14:41:44 +0000 (UTC) Received: from beta.intefo.ch (static-212-101-18-64.adsl.solnet.ch [212.101.18.64]) by mail05.solnet.ch (Postfix) with ESMTP id 1225E39988 for ; Mon, 18 May 2009 14:41:44 +0000 (UTC) Received: from beta.intefo.ch ([127.0.0.1]) by localhost (beta.intefo.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Pme3MN3ZDqzf for ; Mon, 18 May 2009 16:41:43 +0200 (CEST) Received: from [192.168.1.20] (simon.intefo.ch [192.168.1.20]) by beta.intefo.ch (Postfix) with ESMTP id 766E67700DB for ; Mon, 18 May 2009 16:41:43 +0200 (CEST) Message-ID: <4A1173B6.5000805@intefo.ch> Date: Mon, 18 May 2009 14:41:00 -0000 From: Simon Kallweit User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "ecos-devel@ecos.sourceware.org" Subject: lwIP port status Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-05/txt/msg00023.txt.bz2 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