<html><head></head><body><div>Hello Martin,</div><div><span></span></div><div><br></div><div>On Thu, 2021-04-01 at 10:16 +0000, Martin Wilck wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Thu, 2021-04-01 at 12:48 +1000, Erwin van Londen wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>Benjamin has added a marginal_path group(multipath marginal<br></div><div>pathgroups) in<br></div><div>the dm-multipath.<br></div><div><a href="https://patchwork.kernel.org/project/dm-devel/cover/1564763622-31752-1-git">https://patchwork.kernel.org/project/dm-devel/cover/1564763622-31752-1-git</a><br></div><div><a href="mailto:-send-email-bmarzins@redhat.com">-send-email-bmarzins@redhat.com</a>/<br></div><div><br></div><div>One of the intention of the Benjamin's patch (support for maginal<br></div><div>path) is<br></div><div>to support for the FPIN events we receive from fabric.<br></div><div>On receiving the fpin-li our intention was to place all the paths<br></div><div>that<br></div><div>are affected into the marginal path group.<br></div></blockquote><div>I think this should all be done in kernel space as we're talking sub-<br></div><div>millisecond timings here when it comes to fpins and the reaction time<br></div><div>expected. I may be wrong but I'll leave that up to you.<br></div></blockquote><div><br></div><div>Sub-ms latency is impossible with this setup (kernel -> broadcom FC<br></div><div>daemon -> multipathd -> kernel). It's only suitable for "fatal" FPINs<br></div><div>that would suggest taking a path offline on the time scale of minutes.<br></div><div>I suppose that would work well for LN FPINs, but not for the other<br></div><div>types.<br></div></blockquote><div>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.</div><div>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.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>On receiving the congestion notifications our intention is to<br></div><div>slowdown the<br></div><div>work load gradually from the host until it stops receiving the<br></div><div>congestion<br></div><div>notifications.<br></div><div>We need to validate the same how we can achieve the same of<br></div><div>decreasing the<br></div><div>workloads with the help of dm-multipath.<br></div></blockquote><div>Would it be possible to piggyback on the service time path selector<br></div><div>in this when it pertains latency? <br></div></blockquote><div><br></div><div>Not on service-time itself, but someone could write a new path selector<br></div><div>algorithm. IMO we'd still have the problem that this would be seen as a<br></div><div>layering violation. In the long run dm-mpath may need to add transport-<br></div><div>specific callbacks. But for a proof-of-concept, a selector algorithm<br></div><div>with layering violations would be ok, I believe.<br></div></blockquote><div>Is that an offer of volunteering?? <img src="cid:88740517b7df4d6319c3f74bbf138f921aa2fb37.camel@erwinvanlonden.net-0" alt=":-)" width="16px" height="16px"></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>Regards<br></div><div>Martin<br></div><div><br></div></blockquote></body></html>