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.
Okay.
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...
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
