On 13/01/2020 21.56, Radoslaw Zarzynski wrote:
Hi Avi,
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
On Sun, Jan 12, 2020 at 4:46 PM Avi Kivity <avi@scylladb.com> wrote: 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.
Well, that's what I would like to avoid. I'd like a developer to know that if they are developing with the posix stack, the application would work and work well with the native stack, not that they have to retest everything.
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.
That memcpy would be incurred only if the state machine specified it needed its own buffer. If it specified it can run from a stack-provided buffer, it would still be zero copy. What your proposal does is reuse the read(2) call's copy to userspace for the application's purposes - the copy is still there. So the native stack isn't handicapped by this copy, it happens in both.
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).