[openbeosnetteam] Re: Networking Next Steps
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sun, 18 Jun 2006 17:48:57 +0200 CEST
Hi,
Oliver Tappe <openbeos@xxxxxxxxxxxxxxx> wrote:
> BTW: I wonder if we should implement our new stack in C++ instead of
> C (to
> gain type-safety, inheritance and stack-based locking for instance)?
Yes, that sounds nice, even though we're bound to C for the module
interfaces, the internals can be written in C++ (I'll do that, in any
case).
> > Since we are a bit under time pressure to not waste Andrew's work
> > force, I think the best way to start is probably to begin with a
> > very
> > BONE like architecture. That is, I think should start with a
> > replacement for bone_data and start working on the interface level
> > and
> > the stuff that brings it all together (previously called "core").
> Yes, so what exactly do we want to live in the core? As you mentioned
> that
> you would volunteer to work on a net_buffer *module*, the core should
> contain only the layering code that dispatches net_buffers to the
> protocols
> and the code that loads all the modules, right?
I wouldn't mind if the stack module itself would also contain the
net_buffer/data module as well as the socket and maybe even the
datalink layer. At least that are the basics that are always needed, so
it makes sense to put them together in a single add-on (they can still
export multiple modules if we prefer to keep them separated that way).
> [ 8< ]
> > Anyway, there are a couple of things I don't like about BONE, and
> > that
> > is the following:
> > - the headers are just badly organized, there is no distinction
> > between
> > public and private, between userland and kernel headers, it's all
> > just
> > thrown together. That example shouldn't set a standard, and we
> > shouldn't follow it from the start
> Agreed, can't we just keep/update our current public (FreeBSD)
> headers and
> throw away the private ones?
That's more or less what I did for the branch, although I don't like
what's in our public headers, either- they don't seem to be 1:1
FreeBSD, and even if they were, I don't think we should put that much
stuff in there.
They expose too much of the internals, and go way beyond of what is
needed (for example, have a look at sys/socket.h). I would also like to
get rid of sys/ioccom.h, sys/filio.h, etc.
Also, sys/ioctl.h is broken.
> > - I would like to get rid of acronyms like "if" and "dl" and use
> > their
> > full names for structure names and fields; I would also like to
> > remove
> > the "if_" or similar prefixes in the structure fields names
> I personally have nothing to complain about names like net_dl_proto,
> but
> net_datalink_proto would be ok, too.
I'd be thankful for that, even though I'd even call it
net_datalink_protocol ;-)
But if it comes down, I'd prefer net_dl_protocol over
net_datalink_proto. But anyway, I somewhat dislike abbreviations, and
only use them rarely.
> > I'll open a new branch for the stack by simply renaming the FreeBSD
> > branch, okay?
> Fine with me.
Done. I've also added a script to switch the networking stacks.
BTW I've investigated BONE a bit yesterday, and while I said something
like "I can't see any reason why we should create packets faster than
the card can send" before, I would think it might be actually better to
decouple this with a dedicated thread.
The reason is simply to reduce the latency between outgoing packets -
it still doesn't make much sense to prepare 10 packets for sending, but
it makes sense to try to always have one in the queue, so that as soon
as the card is ready, the next one can be send - this could be
especially useful for Gigabit ethernet cards.
Anyway, the current bone_data concept doesn't seem to be too useful for
this, at least, before switching to another thread, we must make sure
there is no user space buffer left in the bone_data object. But I don't
know if there are any cards out there that could work with a couple of
iovecs instead of a single buffer, so there is possibly no reason to be
too smart about this, anyway. I would move that decision to the
interface level, so that we can still find a good way to do this later.
Another problem is that lock_memory() is not really implemented yet,
and I am not sure how expensive it will be yet. So it might make sense
to get rid of the userland buffer early on, which somewhat compensates
the strength of bone_data. Ah well, I think we should ignore this for
now, too.
Bye,
Axel.
Other related posts:
