* NVMe over fabrics - Caching controller Identity data
@ 2017-04-14 17:49 Steve Blightman
2017-04-20 5:47 ` Christoph Hellwig
0 siblings, 1 reply; 3+ messages in thread
From: Steve Blightman @ 2017-04-14 17:49 UTC (permalink / raw)
As I understand it, the linux initiator caches the controller Identity
data and some other values. These only get loaded when it first
connects, or when the controller is reset. Now If a target wishes to
change any of these values, capsule size for instance, it might set the
new values and restart itself, but when the initiator reconnects to an
existing controller, it still has the old values. Is there a way for the
target to force the initiator to reload these values somehow?
^ permalink raw reply [flat|nested] 3+ messages in thread
* NVMe over fabrics - Caching controller Identity data
2017-04-14 17:49 NVMe over fabrics - Caching controller Identity data Steve Blightman
@ 2017-04-20 5:47 ` Christoph Hellwig
2017-04-20 11:46 ` Sagi Grimberg
0 siblings, 1 reply; 3+ messages in thread
From: Christoph Hellwig @ 2017-04-20 5:47 UTC (permalink / raw)
On Fri, Apr 14, 2017@10:49:10AM -0700, Steve Blightman wrote:
> As I understand it, the linux initiator caches the controller Identity data
> and some other values. These only get loaded when it first connects, or
> when the controller is reset. Now If a target wishes to change any of these
> values, capsule size for instance, it might set the new values and restart
> itself, but when the initiator reconnects to an existing controller, it
> still has the old values. Is there a way for the target to force the
> initiator to reload these values somehow?
Identify controller is supposed to be static data for a controller.
If your controller has changed you need to reject the reconnect and
present a new controller.
^ permalink raw reply [flat|nested] 3+ messages in thread
* NVMe over fabrics - Caching controller Identity data
2017-04-20 5:47 ` Christoph Hellwig
@ 2017-04-20 11:46 ` Sagi Grimberg
0 siblings, 0 replies; 3+ messages in thread
From: Sagi Grimberg @ 2017-04-20 11:46 UTC (permalink / raw)
>> As I understand it, the linux initiator caches the controller Identity data
>> and some other values. These only get loaded when it first connects, or
>> when the controller is reset. Now If a target wishes to change any of these
>> values, capsule size for instance, it might set the new values and restart
>> itself, but when the initiator reconnects to an existing controller, it
>> still has the old values. Is there a way for the target to force the
>> initiator to reload these values somehow?
>
> Identify controller is supposed to be static data for a controller.
>
> If your controller has changed you need to reject the reconnect and
> present a new controller.
Given that we support dynamic controllers on the host side we need
to issue identify again.
I have some works to centralize this path and there I do re-identify
the controller.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-04-20 11:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-04-14 17:49 NVMe over fabrics - Caching controller Identity data Steve Blightman
2017-04-20 5:47 ` Christoph Hellwig
2017-04-20 11:46 ` Sagi Grimberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).