Re: dm-multipath - IO queue dispatch based on FPIN Congestion/Latency notifications.

[Erwin van Londen <erwin@xxxxxxxxxxxxxxxxxx>]

Hello Martin,

On Thu, 2021-04-01 at 10:16 +0000, Martin Wilck wrote:

On Thu, 2021-04-01 at 12:48 +1000, Erwin van Londen wrote:

Benjamin has added a marginal_path group(multipath marginal

pathgroups) in

the dm-multipath.

https://patchwork.kernel.org/project/dm-devel/cover/1564763622-31752-1-git

-send-email-bmarzins@xxxxxxxxxx/

One of the intention of the Benjamin's patch (support for maginal

path) is

to support for the FPIN events we receive from fabric.

On receiving the fpin-li our intention was to  place all the paths

that

are affected into the marginal path group.

I think this should all be done in kernel space as we're talking sub-

millisecond timings here when it comes to fpins and the reaction time

expected. I may be wrong but I'll leave that up to you.

Sub-ms latency is impossible with this setup  (kernel -> broadcom FC

daemon -> multipathd -> kernel). It's only suitable for "fatal" FPINs

that would suggest taking a path offline on the time scale of minutes.

I suppose that would work well for LN FPINs, but not for the other

types.

I agree. I was hoping the FC drivers would be able to play a role in this and provide a direct hook into the FPIN notifications in such a way that userspace daemons would not be required and multipath would be able to play a direct role here.

When it comes to latency in a san we're indeed talking about sub-ms when it comes to impacting other parts of the fabrics having an immediate effect on multiple initiators and targets due to the shared nature of the beast.

On receiving the congestion notifications our intention is to

slowdown the

work load gradually from the host until it stops receiving the

congestion

notifications.

We need to validate the same how we can achieve the same of

decreasing the

workloads with the help of dm-multipath.

Would it be possible to piggyback on the service time path selector

in this when it pertains latency?  

Not on service-time itself, but someone could write a new path selector

algorithm. IMO we'd still have the problem that this would be seen as a

layering violation. In the long run dm-mpath may need to add transport-

specific callbacks. But for a proof-of-concept, a selector algorithm

with layering violations would be ok, I believe.

Is that an offer of volunteering??

Regards

Martin

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel