[SPDK] nvmf/rdma: handling QP errors

[SPDK] nvmf/rdma: handling QP errors

[Philipp Skadorov]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

Hi there,
Looking at the list of errors ibv_get_async_event offers - would it make sense to monitor them in the polling loops?
Right now, per my understanding, the only way SPDK gets that things go wrong is: when initiator issues disconnect.
Any thoughts?

Regards,
Philipp

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2177 bytes --]

Re: [SPDK] nvmf/rdma: handling QP errors

[Walker, Benjamin]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

On Thu, 2018-04-05 at 23:17 +0000, Philipp Skadorov wrote:
> Hi there,
> Looking at the list of errors ibv_get_async_event offers – would it make sense
> to monitor them in the polling loops?
> Right now, per my understanding, the only way SPDK gets that things go wrong
> is: when initiator issues disconnect.
> Any thoughts?

I agree with you. Monitoring for network errors this way is probably going to be
the right path forward. The challenge is doing it in a way that doesn't impact
performance, which means doing this polling inline with the code that attempts
to accept new connections. Take a look at the function "spdk_nvmf_rdma_accept",
which periodically polls rdma_get_cm_event to detect new or removed connections.
I wouldn't be surprised if rdma_get_cm_event is actually built on top of
ibv_get_async_event, but it certainly provides less detail.

>  
> Regards,
> Philipp
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk