[openbeosnetteam] Re: Status
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Mon, 12 Jun 2006 15:44:31 +0200 CEST
Hi Oliver,
Oliver Tappe <openbeos@xxxxxxxxxxxxxxx> wrote:
> Reading and trying to grok both our existing stack and the one from
> FreeBSD
> 6.1, I have found the code to be rather big and complicated in subtle
> ways.
I definitely agree :-)
> In order to facilitate getting comfortable with the subtleties of
> such a
> large blob of foreign code, I suppose that it'd be very wise to try
> and
> import the new stack with as few changes as possible. We know that
> the code
[...]
I don't know. It might be wise, and it might even be the shortest way
to achieve something, but I wouldn't like what ends up in our
repository: this large blob of foreign code.
I especially dislike the directory structure and naming scheme found in
BSD code, combined with an extensive use of macros. Furthermore, it
delivers much more than we need.
Since understanding and solving locking issues caused by working around
the netisr stuff requires a good understanding and overview over the
existing code, this is a good source of introducing hard to track bugs
(or performance bottlenecks) as well. We also don't want to end up with
a dozen networking threads if it can be avoided.
In the longer term, I would prefer a BONE like architecture with a
useful separation of code and functionality into modules. That's why I
would like to do this transition module per module.
But anyway, what do you think we should do? Have I managed to alter
your opinion?
> Our current stack bridges the mbuf gap in our interface by using two
> kernel
> threads per interface (rx- and tx-thread) in order to fetch/push data
> from/to the driver (these threads handle mbufs on the stack side and
> raw
> buffers on the driver side). I think this is ok and I'd like to
> preserve
> this approach and just clean up the code for our new stack.
> What I don't like/understand about our current stack is that
> ether_input()
> runs in a thread of it's own, which I find a bit cumbersome, as this
> special
> thread represents a bottleneck (every ethernet frame passes through
> it, not
> matter which interface it came from) and it isn't even necessary (at
> least
> not with the current FreeBSD stack). I'd like to simply get rid of
> that
> ether_input thread and simply run ether_input within the rx-thread of
> every
> interface.
As long as that thread doesn't need too long to process the packets -
every ethernet driver only has a limited number of packets it can keep
around. But we'll see about that, and can definitely start with a
single thread approach.
For what do we need the tx-thread, btw? Is that additional handshake
needed for anything?
> 3.) Related to the netisr stuff, the new stack uses spl...() calls to
> lift
> the current thread to a specific softirq level and splx() do restore
> the
> level later.
> While at first I found it very tempting to simply ignore these calls
> and
> replace them by noops, I am not so sure any more. As far as I can see
> (and
> I'm afraid that isn't very far at all) these calls are used to
> serialize the
> access of several data structures. So we'd probably have to analyze
> each
> occurrence and protect these data structures by corresponding locks.
> Our
> current stack doesn't seem to bother with that, which might or might
> not
> contribute to its instability...
Yes, that kind of functionality is usually also used to serialize
access to whatever data structures.
> 4.) The new stack refers to "Giant", aka the global kernel lock that
> is
[...]
> 5.) Several people have expressed their dislike of sysctl() as means
> to
[...]
> show (whatever the latter is). So in order to avoid using sysctl, we
> should
> discuss how to replace it (ioctl on /dev/net/stack perhaps?) and then
> patch
> these tools to use that new solution instead of sysctl.
Sounds good.
> Ah, and of course, before all that...
>
> 0.) We should import the FreeBSD stack. I'm not very familiar with
> svn, so I
> am not sure how to do this properly. What about doing this?
> - import the FreeBSD-6.1-release netstack into a vendor branch
> - create a new netstack branch of module haiku under team/network
> - copy files from the vendor branch into the netstack branch as
> seems appropriate/necessary
> - start work in the network branch, very likely dragging more files
> from the vendor branch along
>
> Comments on these ideas are very welcome!
What parts of the stack do we want to adopt? I guess net/netinet are
the minimum of what's required (possibly netgraph, too, dunno about the
references yet).
Bye,
Axel.
Other related posts:
