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]

 



>> AFAIK the existing listening ID remains, the notification is
>> informative, it doesn't indicate any CM state has changed.
>
> Gleb, can you confirm that?

In my case, when 2 physical interfaces are bonded and the cable is pulled out for one of them,
the RDMA_CM_EVENT_ADDR_CHANGE event is processed 2 times.

1 for condition isert_np->cm_id == cma_id
        isert_np_cma_handler() is called
        The old cma_id is destroyed and a new one is created
2 for condition isert_np->cm_id != cma_id
        isert_disconnected_handler() is called

As I understand it in this case, RDMA_CM_EVENT_ADDR_CHANGE is not just an informative event.
It is needed to recreate the isert connection (struct isert_conn) for the standby path.
I may be wrong, but the creation of a 'struct isert_conn' is initiated in isert_rdma_accept(),
that is, when the cma_id is created.

Therefore, it seems to me that you need to recreate cma_id,
otherwise who will recreate isert_conn?



[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