Re: [PATCH 1/1] iser-target: Fix handling of RDMA_CV_EVENT_ADDR_CHANGE

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

 




What is this trying to do anyhow? If the addr has truely changed why
does the bind fail?

When the active physical link member of bonding interface in active-standby
mode gets faulty, the standby link will represent the assigned addresses on
behalf of the active link.
Therefore, RDMA communication manager will notify iSER target with
RDMA_CM_EVENT_ADDR_CHANGE.

Ah, here is my recollection...

However I think that if we move that into a work, we should do it
periodically until we succeed or until the endpoint is torn down so
we can handle address removed and restore use-cases.

That soudns better, but still I would say this shouldn't even happen
in the first place, check the address and don't initiate rebinding if
it hasn't changed.

But don't you need to setup a new cm_id for the this notification? It
will remain active?

AFAIK the existing listening ID remains, the notification is
informative, it doesn't indicate any CM state has changed.

Gleb, can you confirm that?

Also it's a bit cumbersome to match addresses in some cases like multi
address interfaces. Almost seems easier to setup a new one...

How so? There is only one address passed to bind. If you create
multiple CM ids to cover all addresses then you need to run a set
algorithm to figure out what cm_ids to destroy and which to
create.

There is one address passed to bind, but I need to check that this
address belongs to the interface, which is what bind does anyways..



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux