FreeLists / openbeosnetteam / [openbeosnetteam] Re: Status

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

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.