Hi Sagi,
On 9/28/2022 10:55 PM, Sagi Grimberg wrote:
Our mpath stack device is just a shim that selects a bottom namespace
and submits the bio to it without any fancy splitting. This also means
that we don't clone the bio or have any context to the bio beyond
submission. However it really sucks that we don't see the mpath device
io stats.
Given that the mpath device can't do that without adding some context
to it, we let the bottom device do it on its behalf (somewhat similar
to the approach taken in nvme_trace_bio_complete);
Can you please paste the output of the application that shows the
benefit of this commit ?
Signed-off-by: Sagi Grimberg <sagi@xxxxxxxxxxx>
---
drivers/nvme/host/apple.c | 2 +-
drivers/nvme/host/core.c | 10 ++++++++++
drivers/nvme/host/fc.c | 2 +-
drivers/nvme/host/multipath.c | 18 ++++++++++++++++++
drivers/nvme/host/nvme.h | 12 ++++++++++++
drivers/nvme/host/pci.c | 2 +-
drivers/nvme/host/rdma.c | 2 +-
drivers/nvme/host/tcp.c | 2 +-
drivers/nvme/target/loop.c | 2 +-
9 files changed, 46 insertions(+), 6 deletions(-)
Several questions:
1. I guess that for the non-mpath case we get this for free from the
block layer for each bio ?
2. Now we have doubled the accounting, haven't we ?
3. Do you have some performance numbers (we're touching the fast path
here) ?
4. Should we enable this by default ?
The implementation look good.
