[openbeosnetteam] Re: Status
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Wed, 14 Jun 2006 12:01:48 +0200 CEST
Marcus Overhagen <marcusoverhagen@xxxxxxxx> wrote:
> 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.
Yes, definitely.
> > > 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.
Since it seems we're currently getting a new idea about porting
FreeBSD, I think that we need a module like that to base the whole
stack upon.
The implementation is allowed to be naive for now, but the API is
important to get right.
I think we should start with bone_data and change/simplify/extend
whereever we see the need.
> 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.
There isn't anything needed beyond supporting different frame sizes,
right?
Bye,
Axel.
Other related posts:
