Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
2) bone_data/BeOS: a buffer consists of several smaller data buffers, joined via iovecs. Does not copy or allocate the data buffers, but only puts them into the queue. Has a separate structure to put the header information into. pro: * very flexible, can be built around existing data buffers * can share buffers * very cheap prepending/appending/splitting * may not need to copy the data at all in the case of out-of-band data and a new networking card * clean API con: * fragments the data a lot - every header added is placed in a separate chunk of memory * many allocations, two for each buffer * needs a special treatment for userland buffers * no linear buffer
This was very similar to my first idea for network buffers, but I see your point keeping fixed size buffers. What if instead of allocating a new buffer for each header, you allocate one "before" buffer and one "after" buffer for all headers and trailers? You could also make the "after" buffer smaller, since few protocols use a trailer.
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
I think I'm confused as well. Do you mean structure headers like the non-packet data in Mbufs? Or actual network headers that get sent over the wire?
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?
Something like TCP, or another type of transfer control might want to use shared buffers as well. In case a particular packet was not ACK'd, a new packet could be sent containing the same data as the original (depending on the protocol, you might be able to just resend the original and not need to share the buffers)
