All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: bugzilla-daemon@bugzilla.kernel.org
Cc: linux-rdma@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [Bug 214523] New: RDMA Mellanox RoCE drivers are unresponsive to ARP updates during a reconnect
Date: Sun, 26 Sep 2021 11:02:32 +0300	[thread overview]
Message-ID: <YVApGIbSLsU2Ap0k@unreal> (raw)
In-Reply-To: <bug-214523-11804@https.bugzilla.kernel.org/>

On Fri, Sep 24, 2021 at 03:34:32PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=214523
> 
>             Bug ID: 214523
>            Summary: RDMA Mellanox RoCE drivers are unresponsive to ARP
>                     updates during a reconnect
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 5.14
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Infiniband/RDMA
>           Assignee: drivers_infiniband-rdma@kernel-bugs.osdl.org
>           Reporter: kolga@netapp.com
>         Regression: No
> 
> RoCE RDMA connection uses CMA protocol to establish an RDMA connection. During
> the setup the code uses hard coded timeout/retry values. These values are used
> for when Connect Request is not being answered to to re-try the request. During
> the re-try attempts the ARP updates of the destination server are ignored.
> Current timeout values lead to 4+minutes long attempt at connecting to a server
> that no longer owns the IP since the ARP update happens. 
> 
> The ask is to make the timeout/retry values configurable via procfs or sysfs.
> This will allow for environments that use RoCE to reduce the timeouts to a more
> reasonable values and be able to react to the ARP updates faster. Other CMA
> users (eg IB or others) can continue to use existing values.
> 
> The problem exist in all kernel versions but bugzilla is filed for 5.14 kernel.
> 
> The use case is (RoCE-based) NFSoRDMA where a server went down and another
> server was brought up in its place. RDMA layer introduces 4+ minutes in being
> able to re-establish an RDMA connection and let IO resume, due to inability to
> react to the ARP update.

RDMA-CM has many different timeouts, so I hope that my answer is for the
right timeout.

We probably need to extend rdma_connect() to receive remote_cm_response_timeout
value, so NFSoRDMA will set it to whatever value its appropriate.

The timewait will be calculated based it in ib_send_cm_req().

Thanks

> 
> -- 
> You may reply to this email to add a comment.
> 
> You are receiving this mail because:
> You are watching the assignee of the bug.

  reply	other threads:[~2021-09-26  8:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24 15:34 [Bug 214523] New: RDMA Mellanox RoCE drivers are unresponsive to ARP updates during a reconnect bugzilla-daemon
2021-09-26  8:02 ` Leon Romanovsky [this message]
2021-09-26 17:36   ` Chuck Lever III
2021-09-27 12:09     ` Leon Romanovsky
2021-09-27 12:24       ` Jason Gunthorpe
2021-09-27 12:55         ` Mark Zhang
2021-09-27 13:10           ` Jason Gunthorpe
2021-09-27 13:32             ` Haakon Bugge
2021-10-15  6:35               ` Mark Zhang
2021-09-27 16:14       ` Chuck Lever III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YVApGIbSLsU2Ap0k@unreal \
    --to=leon@kernel.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-rdma@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.