FreeLists / openbeosnetteam / [openbeosnetteam] Re: net buffers

[Oliver Tappe <openbeos@xxxxxxxxxxxxxxx>]

Hi,

On 2006-06-20 at 14:43:12 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
wrote:
> Hi there,
> 
> I had a long talk with Marcus yesterday, as we were discussing the
> various concepts (mbuf vs. bone_data vs. sk_buff) as well as the needs
> of current (Gigabit ethernet) hardware.
> 
> To summarize, I give you a short overview over each technique combined
> with a short pro/con list.

[ 8< ]

> 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
> 
> 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.
> The buffers have reference counters and may be shared between multiple
> packets.
> 
> pro:
> * clean API
> * little fragmentation of data, perfect for high speed ethernet
> * can share buffers
> * simple allocator
> * flexible (would work with variable buffer sizes as well)
> * very cheap prepending/appending if there is enough space left
> * still cheap prepending/appending if a new buffer is needed
> * splitting a buffer is cheap

How come, I thought we'd have fixed 2k buffers, so wouldn't splitting incur 
a copy?

> * must always copy data at least once

I consider that a con >;o)

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

> * usually a linear buffer, but you can't count on it
> * potentially wastes a lot of memory - if this starts to become a
> problem, we can easily introduce a second default buffer size; it
> shouldn't matter that much for the non-server case, though

I agree, this shouldn't really be a problem for the desktop PC.

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

cheers,
        Oliver