It appears that we are coming across 2 kinds of requirements for kiobuf
vectors - and quite a bit of debate centering around that.
1. In the block device i/o world, where large i/os may be involved, we'd
like to be able to describe chunks/fragments that contain multiple pages;
which is why it make sense to have a single <offset, length> pair for the
entire set of pages in a kiobuf, rather than having to deal with per page
2. In the networking world, we deal with smaller fragments (for protocol
headers and stuff, and small packets) ideally chained together, typically
not page aligned, with the ability to extend the list at least at the head
and tail (and maybe some reshuffling in case of ip fragmentation?); so I
guess that's why it seems good to have an <offset, length> pair per
page/fragment. (If there can be multiple fragments in a page, even this
might not be frugal enough ... )
Looks like there are 2 kinds of entities that we are looking for in the kio
- A collection of physical memory pages (call it say, a page_list)
- A collection of fragments of memory described as <offset, len>
tuples w.r.t this collection
(offset in turn could be <index in page-list, offset-in-page> if it
helps) (call this collection a frag_list)
Can't we define a kiobuf structure as just this ? A combination of a
frag_list and a page_list ? (Clone kiobufs might share the original
kiobuf's page_list, but just split parts of the frag_list)
How hard is it to maintain and to manipulate such a structure ?
BTW, We could have a higher level io container that includes a <status>
field and a <wait_queue_head> to take care of i/o completion (If we have a
wait queue head, then I don't think we need a separate callback function if
we have Ben's wakeup functions in place).
Or, is this going in the direction of a cross between and elephant and a
bicycle :-) ?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/