On 14/01/2020 11.30, Avi Kivity wrote:
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.
Perhaps we can add placing_data_source data_source::to_placing_data_source() && Which converts a regular data_source to a placing_data_source, which gets as input from the user the buffers to use. The default placing_data_source would just copy data from the original data_source to the buffers provided by the user. The placing_data_source provided by posix_data_source_impl::to_placing_data_source() would cooperate with the posix stack to read directly into the buffers provided by the user (reusing the copy performed by the system call). If a data movement engine is available, the native stack might program it to perform the copy.