>> I’d really like a solution to this, but I don’t think one is >> available given the constraints. > > Now that I know I understand it, I will at least provide > some review comments on the patches. I'll also think about > it a little. My instinct says there should be no need to > make the copies, but the devil will be in the details.
Yeah, it seems like it should be simpler. To fix it, I think we would have to either commit a layering violation (decode the call ops’ response sizes in the message receive flow) or change the interface to osd_client (don’t provide preallocated pagevecs for call response data even though that’s what’s done for other types of ops). I’m the new guy, though, so it’s certainly possible I’m missing something. >> I was told that the preferred way to proceed for now was to avoid >> changing the osd_client interface and to handle this case in >> osd_client instead of the messaging layer. Given those constraints, >> it was agreed in the standups and on #ceph-devel that it should be >> done this way. > > Sorry, I haven't been keeping up with all the activity on the > mailing list. I pay closest attention to patches to the kernel > code. Well, this was worked out mainly in the standups and on IRC. There wasn’t a mailing list discussion on it. Having said that, the attention to the patch is certainly appreciated. > OK, well I'll go look at that code path again to see if I > can > come up with any bright ideas. Thanks very much. -Doug-- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
