On Tue, Jan 14, 2025 at 11:31:00PM +0100, Martin Wilck wrote: > On Mon, 2025-01-06 at 12:39 -0500, Benjamin Marzinski wrote: > > On Fri, Dec 20, 2024 at 04:25:22PM +0530, Muneendra Kumar M wrote: > > > Hi Benjamin, > > > Thanks for the changes. > > > But below is the reason why we didn't add support to set the rport > > > port_state to marginal for NVMe devices > > > > > > In the case of SCSI once rport-state is set to Marginal , > > > If any pending I/O's on the marginal path hit's the scsi-timeout > > > (after > > > abort success) the scsi-layer checks the rport-state and If the > > > rport-state is set to Marginal it will not do any retries on the > > > Marginal > > > path instead the I/O > > > Will be retried on the other Active paths. > > > > > > > > > This particular functionality(checking the rport-state and acting > > > accordingly) we didn't add( as far I know) in the case of NVME and > > > we need > > > to check how we can handle this in the case of NVME . > > > That's the reason we didn't set the port state to Marginal in the > > > case of > > > NVMe. > > > > > > > > > In a brief SCSI layer handles the case when the rport-state is set > > > to > > > Marginal whereas in NVMe it doesn't(AFIK). > > > > > > Atleast with the below changes we make sure that once we get the > > > FPIN-LI > > > notification we will set the affected path , as well as the rport- > > > state to > > > Marginal irrespective of SCSI and NVMe. > > > > > > I am just thinking that until we have some changes in the NVME > > > driver to > > > handle (the rport-state to marginal) this changes doesn't show any > > > impact > > > in the case of NVMe > > > other then keeping it on par with SCSI implementation. > > > > > > Please let me know your opinion on the same. > > > > The request to do this came because the user wanted to see which > > target > > ports were effected, but when they looked, none of them we in the > > Marginal state. So there is some value in this for users, even if the > > systems behavior doesn't change because of it. > > Please add a note to the commit message explaining this. > > I'm actually a bit concerned about it ... won't other users be even > more confused when they see the path devices as marginal but don't > observe any change in the system's usage of these paths? Sure, I can add a commit message. But while this isn't implemented in the NVMe layer, multipath will still route future IO differently. So, any IO that multipath has already dispatched to the now marginal path won't get treated differently, users will notice a change in IO patterns going forward. Right? -Ben > > Regards, > Martin
