From: Simon Kallweit <simon.kallweit@intefo.ch>
To: "ecos-devel@ecos.sourceware.org" <ecos-devel@ecos.sourceware.org>
Subject: lwIP port status
Date: Mon, 18 May 2009 14:41:00 -0000 [thread overview]
Message-ID: <4A1173B6.5000805@intefo.ch> (raw)
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
next reply other threads:[~2009-05-18 14:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-18 14:41 Simon Kallweit [this message]
2009-07-22 10:34 ` MaxiD
2009-07-22 11:22 ` Simon Kallweit
2009-08-18 16:59 ` John Dallaway
2009-08-18 17:33 ` Simon Kallweit
2009-08-19 7:11 ` John Dallaway
2009-08-19 9:21 ` Sergei Gavrikov
2009-08-19 12:11 ` Simon Kallweit
2009-08-19 12:10 ` Simon Kallweit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A1173B6.5000805@intefo.ch \
--to=simon.kallweit@intefo.ch \
--cc=ecos-devel@ecos.sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).