From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============4600974528735200317=="
MIME-Version: 1.0
From: Walker, Benjamin <benjamin.walker at intel.com>
Subject: Re: [SPDK] nvmf/rdma: handling QP errors
Date: Fri, 06 Apr 2018 17:37:53 +0000
Message-ID: <1523036198.3669.7.camel@intel.com>
In-Reply-To: DM5PR04MB0379711EF5B8A4C7118C41C386BB0@DM5PR04MB0379.namprd04.prod.outlook.com
List-ID: <spdk@lists.01.org>
To: spdk@lists.01.org

--===============4600974528735200317==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

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 =E2=80=93 would =
it make sense
> to monitor them in the polling loops?
> Right now, per my understanding, the only way SPDK gets that things go wr=
ong
> 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 imp=
act
performance, which means doing this polling inline with the code that attem=
pts
to accept new connections. Take a look at the function "spdk_nvmf_rdma_acce=
pt",
which periodically polls rdma_get_cm_event to detect new or removed connect=
ions.
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

--===============4600974528735200317==--