[openbeosnetteam] Re: Status
- From: Marcus Overhagen <marcusoverhagen@xxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 14 Jun 2006 10:35:06 +0200 (CEST)
Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> 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.
This is what I also would like to have.
Including a module that provides a socket api for use inside the kernel,
and a module that provides native access to mbufs so that drivers can
bypass the read/write driver hooks.
> > 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.
I think this is ok, as long as we have a native interface to the mbufs that can
be used
when optimizing a driver.
I planned to work on a mbuf like structure to handle all packet data inside the
stack,
extending it to better support memory alignment constrains, jumbo frames, and
optaining of physical addresses during initalization of the buffer queue,
instead
of each time a buffer is used. However, I have postponed that now, to not
interfere
with Andrews work.
> > 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.
Thats basically locking by disabling / enabling interrupts (which doesn't work
on SMP systems without giant lock). Ignoring it is not an option.
> 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).
I would like to keep jumbo frame support, for high speed gigabit transfers.
please do not remove this, even if it may make things slightly more complicated.
regards
Marcus
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 44,85 ? inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
Other related posts:
