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. > 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 _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
