[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: Waldemar Kornewald <wkornew@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 16 Mar 2006 14:02:59 +0100
Hi Joseph,
Joseph Liu wrote:
Dragonfly bsd would be a little more work of porting another set of
apis and debugging it. If we decide on implementing lwkt in our kernel
or any kind of cpu affinity in the future, dragonfly bsd seems like a
better bet just to get it over with. If we aren't I would guess
probably sticking with plain old freebsd to user their size as a
crutch. As of the current state (i've been pulling fromallbsd.org, so
maybe freebsd 5.x?), freebsd and dragonfly's net stack look similar.
I'd really like other people's input before I start hacking away.
With DragonFly, we would have to modify our scheduler to allow for
binding a thread on a specific CPU (or is that already possible?).
Hopefully, that does not make Haiku very unstable... Also, I don't like
"hacky" solutions. If it's done then it must be done right. I'm not sure
whether we want to have LWKT for R1. What do the other Haiku developers
think? I want to have something like LWKT because it could make our
threading code (drivers, netstack, etc.) easier to maintain and
understand. It depends on how much time we want to spend on the netstack
and how many people would volunteer. If we're going to get LWKT for R2,
anyway, then maybe it's a better idea to do it now than to port a new
netstack, again. But if the kernel team thinks that we will do our own
thing (maybe RCU (read-copy-update) or STM (software transactional
memory)) then let's use FreeBSD.
About RCU:
http://en.wikipedia.org/wiki/Read-copy-update
BTW, there already exist a few STM implementations in/for C. But we'd
probably have to implement it in C++ (maybe with templates?) to get
everything right and fully usable for C++...just loud thinking...
Rewriting LWKT calls to use mutex functions is not acceptable because
LWKT is the only thing that makes me like DFly's netstack and I want the
netstack to be (mostly) maintained by the BSD coders, not us. Importing
changes from their repos should be as simple as possible. Our team is
small and we want to focus on *usability*. The netstack is merely a
"tool" that should not be cared about. We need things like ZeroConf,
WiFi with WPA2, networking profiles with auto-detection,
auto-configuration, Bluetooth networks, ...
But in case we have to work on the netstack in order to get some of
these features integrated then it must be easy. That's the only reason
for me to have this DragonFly vs FreeBSD discussion.
Axel Dörfler wrote:
As the kernel guy on this list, I must say that lwkt doesn't sound too
tempting for me. In fact, I don't really see the point in serializing
tasks this way - in many ways, it's like a slightly relieved giant
lock. I didn't read over the DragonFly code, though, I'm judging from
what I read about it only - maybe there is a striking example in there
that even I might find useful :-)
Please take a look at this excellent article:
http://en.wikipedia.org/wiki/Serializing_tokens
Here is an ML-thread in which Matt describes serializing tokens:
http://thread.gmane.org/gmane.os.dragonfly-bsd.kernel/4436
One interesting quote:
For example, Jeff's work on the TCP stack is moving all protocol processing
for a particulr PCB to a particular cpu. Since only one cpu is working
on a particular PCB, the protocol code can access that PCB without
acquiring any locks, mutexes, or tokens of any sort.
In FreeBSD there are functions that pass mutexes around to other
functions, so they can release the mutex in order to get around
dead-locks. The implementation is a hell to understand and follow. OTOH,
serializing tokens have the problem that when holding a token you must
either know that the functions you call will not block or you must
program defensively and update possibly affected variables after calling
the function.
I can only say that even my (unfinished) PPP stack implementation uses
LockWithTimeout (in one place) to get around dead-locks. I'd like to
rewrite the whole PPP threading code into something much simpler. Even
if that means it becomes less multi-threaded...but first we need a
working netstack.
RCU is more complicated than tokens when updating multiple items in one
atomic operation and Linux seems to have serialization problems with
them. OTOH, all alternatives have their pitfalls. STM does not have the
"nested token" problem (i.e.: called functions might block) and it is
easy to develop apps with it, but it's limited to reversible operations
(i.e.: i/o is not allowed!!!) and an STM API would be more difficult to
implement than the other alternatives.
I don't see what you mean with it looking like Big Giant Lock. Could you
explain to me what exactly you meant? Simply the fact that threads stick
to a CPU? Just distribute more threads across CPUs...
Please vote now! :)
IMHO: Let's go for tokens (LWKT) and DragonFly because
1. we get a good, existing, usable solution (BSD license)
2. tokens are more flexible than the other ones
(e.g.: they can implement RCU-like operation)
3. LWKT scales very well
Bye,
Waldemar
Other related posts:
