Re: [PATCH RFC] nvme-fc: FPIN link integrity handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 08/03/2024 16:09, Hannes Reinecke wrote:
On 3/8/24 11:38, Sagi Grimberg wrote:

On 07/03/2024 14:13, Hannes Reinecke wrote:
On 3/7/24 13:01, Sagi Grimberg wrote:

[ .. ]

stopped is different because it is not used to determine if it is capable for IO (admin or io queues). Hence it is ok to be a flag.


But wait, isn't that precisely what we're trying to achieve here?
IE can't we call nvme_quiesce_io_queues() when we detect a link integrity failure?

Lemme check how this would work out...

So yeah, we could introduce a new state, but I guess a direct transition
to 'DEAD' is not really a good idea.

How common do you think this state would be? On the one hand, having a generic state that the transport is kept a live but simply refuses to
accept I/O; sounds like a generic state, but I can't think of an
equivalent in the other transports.

Yeah, it's pretty FC specific for now. Authentication is similar, though, as the spec implies that we shouldn't sent I/O when authentication is in progress.

If this is something that is private to FC, perhaps the right way is to add a flag for it that only fc sets, and when a second usage of it appears,
we promote it to a proper controller state. Thoughts?

But that's what I'm doing, no? Only FC sets the 'transport blocked'
flag, so I'm not sure how your idea would be different here...

I know, I just came a full circle with our discussion :)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux