Re: [PATCH 0/3] Provide more fine grained control over multipathing

[Sagi Grimberg]

[so much for putting out flames... :/]

> This projecting onto me that I've not been keeping the conversation
> technical is in itself hostile.  Sure I get frustrated and lash out (as
> I'm _sure_ you'll feel in this reply)

You're right, I do feel this is lashing out. And I don't appreciate it.
Please stop it. We're not going to make progress otherwise.

> > Can you (or others) please try and articulate why a "fine grained"
> > multipathing is an absolute must? At the moment, I just don't
> > understand.
>
> Already made the point multiple times in this thread [3][4][5][1].
> Hint: it is about the users who have long-standing expertise and
> automation built around dm-multipath and multipath-tools.  BUT those
> same users may need/want to simultaneously use native NVMe multipath on
> the same host.  Dismissing this point or acting like I haven't
> articulated it just illustrates to me continuing this conversation is
> not going to be fruitful.

The vast majority of the points are about the fact that people still
need to be able to use multipath-tools, which they still can today.
Personally, I question the existence of this user base you are referring
to which would want to maintain both dm-multipath and nvme personalities 
at the same time on the same host. But I do want us to make progress, so
I will have take this need as a given.

I agree with Christoph that changing personality on the fly is going to
be painful. This opt-in will need to be one-host at connect time. For
that, we will probably need to also expose an argument in nvme-cli too.
Changing the mpath personality will need to involve disconnecting the
controller and connecting again with the argument toggled. I think this
is the only sane way to do this.

Another path we can make progress in is user visibility. We have
topology in place and you mentioned primary path (which we could
probably add). What else do you need for multipath-tools to support
nvme?