Well this sets a lower bound on the state of the art that is in any case orders of magnitude higher than what many people suffer from in industry practice.
Just to restate what I said---you cannot use this in its current state in production (or industry), ever. And by the time it becomes useful, it becomes a natural solution because the infrastructure supports it.
Every person that works on kernel knows the overhead that comes with abstractions. Everybody that has worked with DPDK knows that you can get 20Mpps+ on a single core.
All they have done is to "frame" the usage and the term RPC differently ... i.e., it's all story telling and no real meat :)
Look at the previous set of publications by the same author: e.g., Achieve a Billion Requests Per Second Throughput on a Single Key-Value Store Server Platform, etc. they are all based on a single assumption that if you don't implement X and Y in your stack you can get better performance. Of course, you can. If you use your calculator to only compute 2+2 you might as well hardcode 4 as the output of your calculator.
They are not setting a lower bound. They are hardcoding and bypassing the parts they don't find useful.
I agree that our code is not production-ready, but an industry team at Intel is trying eRPC out: https://github.com/daq-db.
I am curious to know what features you believe we omitted in our ISCA 15 paper. Our key-value store (https://github.com/efficient/mica2) supports a memcached-like API over UDP.
