On 14/01/2020 11.30, Avi Kivity wrote:
On 13/01/2020 21.56, Radoslaw Zarzynski wrote:
Hi Avi,
On Sun, Jan 12, 2020 at 4:46 PM Avi Kivity <avi@xxxxxxxxxxxx> 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.
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.
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
