I have a deeper question about bufferlist. Essentially, I have a specific pattern that I want to implement and there are a couple of options about how to orchestrate the bufferlists. I'm looking for an opinion on the best choice. Naturally, ::encode is the still the theme of the day. I've been thinking about an alternate approach to the encoding problem that approaches it more globally than the per-field, incremental approach that you're looking at. Specifically, thinks like the # of low-order bits being zero (512, 4K, block sizes...) are really more efficiently encoded globally. Also, the size of an LBA address is more efficiently coded locally (and decoded!). The major problem with these techniques is that you have to encode the shift values earlier in the buffer from the actual data values. Meaning that EITHER you know the value ahead of time (from, say device information, or config parameters) OR you have to scan the data to determine the correct value. I've been thinking about a third/hybrid scheme, wherein you assume a large value, start to encode the data and then backtrack (i.e., abandon and restart) if you discover that your assumed value is incorrect. One pattern to do this is the do the encode into a separate bufferlist. If the encode fails you can bufferlist::clear (or delete and recreate) and restart. Once you've succeeded you append then the new buffer to the original buffer. The other pattern is to somehow mark the original buffer (bufferlist::size) when you start and then if you fail, you trim (resize) the original buffer back to the mark point. Once you succeeded you're done. Which do you think would be faster? -- 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
