Hi Avi,
On Sun, Jan 12, 2020 at 4:46 PM Avi Kivity <avi(a)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