> On Apr 27, 2015, at 12:15 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > Two basic approaches come to mind: > > 1) add an up-call between the front and data portions. Right now we have > a get_reply between header and front that is used to get the buffers for > front (and data). We could add a second that comes after front to prepare > the data buffers. This would basically change teh sequence from > > - read header > - get/allocate ceph_msg, along with front, middle, and data buffers > - read front, middle, data > - dispatch message > - decode > - process > > to > > - read header > - get/allocate ceph_msg, along with front, maybe middle, and data buffers > - read front, middle > - call get_data hook > - decode front, prepare/allocate data buffers > - read data > - dispatch message > - process > > I think that's a viable approach, but it means a fair bit of refactoring > to separate the decoding from the processing (at least for > osd_reply)--right now those two steps are combined in all of the > handle_* functions. In the kernel client, the data buffers are allocated before the message is even sent. The messaging code reads the reply data directly into those preallocated buffers. If we add a call up to decode the message size and allocate the data buffers when we process the reply, we have to change the osd_client interface. > 2) Introduce a protocol change so that the section boundaries are > described in a generic way. Even more work! We could also pad the relevant op replies so that each has a fixed length. It would be a protocol change, but a smaller one, I assume. > Given the only uesrs we have in mind have very small data payloads, > copying seems simplest to me, but it's up to you guys. Maybe there is > something much simpler I'm missing? Somehow we have to do the front > parsing before reading data... and probably we want to avoid parsing it > twice... This solution just feels hacky and inefficient, so I think there is a desire to feel like we at least tried to come up something simpler and more efficient before proceeding. -Doug-- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
