[openbeosnetteam] Re: net buffers
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Tue, 20 Jun 2006 18:03:22 +0200 CEST
Hi,
Oliver Tappe <openbeos@xxxxxxxxxxxxxxx> wrote:
> [ 8< ]
> > * splitting a buffer is cheap
> How come, I thought we'd have fixed 2k buffers, so wouldn't splitting
> incur
> a copy?
No, because sharing the backing buffer is supported. You will just need
a second data buffer if you intend to prepend more data to the second
half (likely, but acceptable).
> > * must always copy data at least once
> I consider that a con >;o)
To make this point clear: *YES* it's a con, I mixed that up, even
twice, sorry :-)
> > con:
> > * since a buffer has a header, it cannot be built from an existing
> > data
> > buffer
> Hm, above you said the header would be separate, so why couldn't an
> existing buffer be integrated into the structure? I'm confused...
The data buffer itself has a header as well. Just the net_buffer
structure is separate, unlike with mbufs. I am not sure how large it
gets yet, as we might need it to store protocol related data as well,
but it could probably even placed in a data buffer as well.
[...]
> > The current net_buffer API would defnitely look different than it
> > does
> > now, but what do you think? Does this sound like something we want
> > to
> > pursue? I haven't worked out the details yet, but the only
> > questionable
> > thing is how to design the buffer sharing properly (I have an idea
> > for
> > now, but that's not that clean).
> I wonder where buffer sharing would be used? How many places are
> there in
> the stack that could make use of shared buffers? Multicast comes to
> my
> mind, but what else?
Just consider fragmentation - when you receive a "packet is too large"
error, you may want to split the existing packet in half, instead of
copying it's second half over to a new buffer. That probably won't
happen too often in normal operation, but if the system is in NAT mode
or something similar (routing), this could happen as well frequently.
Bye,
Axel.
Other related posts:
