Hi Avi, On Sun, Jan 12, 2020 at 4:46 PM Avi Kivity <avi@scylladb.com> wrote:
The goal is not to require different optimization techniques or code paths for the two stacks. And it is a challenge to do this well.
Yeah, it brings even more headache after including a requirement to handle both stacks efficiently – without sacrificing one for the sake of another. I fully understand the strong desire to keep the paths consistent. It saves a lot of problems that could come because of developing on POSIX while deploying on native, to exemplify. What I would likely advocate for is the presence of a switch that would allow application to differentiate paths for the sake of maximal performance but under strict rule: if somebody wishes to use a knife instead of a peeler, it's his own responsibility and problem if he cuts his fingers off.
The application would provide the buffers for the data_source, and seastar would take care of the copying if the data_source cannot use the buffer directly (the native stack case).
Yes, that's a possibility. The trade-off is introduction of memcpy() to the native. At the moment I can't say how much a problem it would be in practice. There was a promising experiment with crimson-msgr on top of DPDK but the storage component was excluded (no SPDK at the moment). Regards, Radek