On Wed, 2025-01-15 at 13:59 -0500, Benjamin Marzinski wrote: > 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? Ok. I may have misunderstood Muneendra's reply. I admit I didn't double check in depth. I may also have mixed up native and dm multipath behavior. Regards Martin
