[openbeosnetteam] Re: net buffers

> 3) sk_buff/Linux: variable sized allocations, single buffer per packet,
> leaves space in the beginning for additional headers, and space at the
> end for additional data. Also has a separate structure for the header.
> pro:
> * linear buffer
> * no fragmentation of data
> * clean API
> * very cheap prepending/appending *if* there is enough space left
> * must always copy data at least once

Doesn't this last point a a negative one?

> 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...

> 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...

> The buffers have reference counters and may be shared between multiple
> packets.

A big plus to parallelized as much as possible the stack, and that is one big
issue in our current stack mbuf implementation.

> pro:
> [...]
> * must always copy data at least once

Again, why is it a pro point?

> con:
>
> 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?

> Does this sound like something we want to
> pursue?

I'm convinced it the way to go, yes.

> 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?

- Philippe Houdoin

Other related posts: