Subtask #4125
closedFeature #3761: kernel messenger: need to support multiple ops per request
kernel messenger: support multiple sources of data
0%
Description
We need to allow the osd client to have an array of osd ops
such that each can supply its own buffer for sending and/or
receiving data to the osd.
There was support added for supplying small amounts of data
to be sent, along with an array of pages into which response
data can be received at one time. This took the form of the
"trail" of a message, which was put in place to allow a class
method call to define its class, method, and input data as
well as the buffer to hold the result. But this is a little
bit kludgy and in any case is restrictive in ways that won't
work for what we need.
I came up with an approach I'd like to pursue to implement
this though. I can and will break it down into smaller tasks
related to this one.
The basic idea is to generalize the way the trail of a message
is defined, so that instead of a pagelist, it becomes a list
of descriptors, each of which defines a place to hold data to
send. More than one type of data holder will be allowed,
including a pagelist, but also including an array of pages as
well as a bio list. Interface routines will allow adding a new
data holder of a given type to the end of the trail.
When the messenger is sending the trail portion of the message
it will cycle through each of these, providing pages from each
data holder in calls to sendmsg() to send them over the wire.
My hope is that this capability can then be moved in to replace
the pages, pagelist, bio, and trail pieces in a ceph message
structure with a single unified chain of data descriptors.
Or more likely, two chains, one describing data to send and
one describing places to put received response data.
OK, that's the general idea, I'll offer more with some updates.