[openbeosnetteam] Re: net buffers
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Tue, 20 Jun 2006 18:58:57 +0200 CEST
Philippe Houdoin <philippe.houdoin@xxxxxxx> wrote:
> > I've thought a bit about it, and I think best suited for us might
> > be a
> > mix between mbufs and sk_buffs:
> > - a separate header structure with a list of attached buffers
> > - fixed sized 2k buffers with a header and reserved space to place
> > headers
> Looks not that different from Marrow net_data to me. Except for the
> reserved
> headers space in each 512k (bad default size IMHO) buffers as the
> valid data
> are kinda "centered" in each chunk, leaving spaces at both head and
> tail...
Maybe I should have discussed Marrow as well, but as far I can see, it
has some more problems:
- pretends to support buffer sharing, but has no reference counting
- usually fragments data
- wastes even more memory, since it always inserts data in the middle
(might be okay for 512 bytes buffers, but not if it's larger)
- besides the 512 fixed size buffers, it also supports arbitrary sized
buffers - which aren't that cheap
- any data going into the buffers must be copied
- prepending might be more expensive, as it maintains an array of
iovecs (compared to a linked list) - but that case is not implemented
yet, anyway
I must admit though, that I don't understand the large buffer handling
(if that's there at all, doesn't look like it), so I might have
evaluated it incorrectly.
> > Since a standard ethernet frame is 1500 bytes long, and a jumbo
> > frame
> > is 9000 bytes, we would always need a single buffer in the ethernet
> > frame case (and can still leave a generous amount of space for
> > headers), and 5 for the jumbo frames at maximum.
> Looks good to me. 2048 bytes is often the de-facto ring buffers size
> of ethernet
> adapters these days and I'll bet they'll cluster these to support
> jumbograms in
> the future...
That's how gigabit ethernet cards already work.
> > The current net_buffer API would defnitely look different than it
> > does
> > now, but what do you think?
> Hum, why the API should change that much if the behind the scene
> buffers and
> headers are change? Unless we have to access our net buffers
> internals (glups!)
> the API could be very stable, no?
Not really, as the current API assumes that data is put into the buffer
like what BONE does.
I'd also like to give direct buffer access in case there is a long
enough linear buffer for headers etc.
Also, protocols might want to have a per buffer storage as well. This
could be placed in the header as well, but we'll see how that turns
out.
> > 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).
> Care to elaborate your current idea about buffer sharing?
As I said, it's not a very clean solution, but it's basically looking
like this:
that's the header each data buffer begins with:
struct net_buffer_header {
addr_t physical_address;
size_t size;
int32 ref_count;
net_buffer_node nodes[0];
};
And that's the node header that each reference to the buffer get:
struct net_buffer_node {
list_link link;
net_buffer_header *header;
uint8 *data;
size_t size;
size_t free_head;
size_t free_tail;
};
The nodes are placed at the top of the buffer, cutting into the area
for protocol headers - since 2k is big enough to have this extra data
in there plus the additional ethernet frame.
This way, we could also reserve protocol specific data in that
location, as well as the net_buffer structure itself - but I'm not sure
about that yet. Comments and suggestions are, as always, welcome.
The networking protocols would need to report their requirements (for
headers and extra data) to the stack in advance, if possible, to be
able to use an ideal free_head value for each incoming or outgoing
buffer.
Bye,
Axel.
Other related posts:
