From: Honggang LI <honli@redhat.com>
To: Christopher Lameter <cl@linux.com>
Cc: "Håkon Bugge" <haakon.bugge@oracle.com>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Mark Haywood" <mark.haywood@oracle.com>,
"OFED mailing list" <linux-rdma@vger.kernel.org>
Subject: Re: Is there a working cache for path record and lids etc for librdmacm?
Date: Wed, 25 Nov 2020 16:10:57 +0800 [thread overview]
Message-ID: <20201125081057.GA547111@dhcp-128-72.nay.redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2011241859340.286936@www.lameter.com>
On Tue, Nov 24, 2020 at 07:01:25PM +0000, Christopher Lameter wrote:
> On Mon, 23 Nov 2020, Håkon Bugge wrote:
>
> > > Got version 33.0 from Redhat with the option. Set it but ibacm still times
> > > out when trying to contact the SM.
> >
> > Contact the peer ibacm, that is. Is it started?
>
>
> It can contact the peer ibacm if its running on a particular host. Then
> the resolution succeeds. But we want ibacm to talk to the subnet manager.
>
> > And, ib_acme bypasses the kernel_only check. I assume a real app (e.g.,
> > qperf <destination_ip> -cm1 rc_bw) would work, but incur an excess delay
> > due to the ibacm timeout, before failing back to the kernel neighbour
> > cache.
>
> Ok. But what does it matter?
>
>
> How do I figure out why ibacm is not talking to the subnet manager?
No, you can't talking to subnet manager, if you resolve IPoIB IP address
or hostname to PathRecord. The query MAD packets will be send to one
multicast group all ibacm service attached.
To resolve IPoIB address to PathRecord, you must:
1) The IPoIB interface must UP and RUNNING on the client and target
side.
2) The ibacm service must RUNNING on the client and target.
Thanks
next prev parent reply other threads:[~2020-11-25 8:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 2:57 Is there a working cache for path record and lids etc for librdmacm? Christopher Lameter
2020-11-17 8:46 ` Jens Domke
2020-11-17 14:20 ` Christopher Lameter
2020-11-17 19:33 ` Jason Gunthorpe
2020-11-20 18:05 ` Christopher Lameter
2020-11-20 18:34 ` Håkon Bugge
2020-11-22 12:49 ` Christopher Lameter
2020-11-22 15:50 ` Håkon Bugge
2020-11-22 19:22 ` Christopher Lameter
2020-11-23 12:50 ` Christopher Lameter
2020-11-23 19:01 ` Håkon Bugge
2020-11-24 19:01 ` Christopher Lameter
2020-11-25 8:10 ` Honggang LI [this message]
2020-11-25 16:43 ` Christopher Lameter
2020-11-27 14:52 ` Håkon Bugge
2020-11-30 8:24 ` Christopher Lameter
2020-12-04 11:17 ` Håkon Bugge
2020-12-05 11:50 ` Christoph Lameter
2020-12-07 10:28 ` Christoph Lameter
2020-12-07 21:08 ` Mark Haywood
2020-12-08 8:59 ` Christoph Lameter
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=20201125081057.GA547111@dhcp-128-72.nay.redhat.com \
--to=honli@redhat.com \
--cc=cl@linux.com \
--cc=haakon.bugge@oracle.com \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.org \
--cc=mark.haywood@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox