From: Christoph Lameter <cl@linux.com>
To: "Håkon Bugge" <haakon.bugge@oracle.com>
Cc: Honggang LI <honli@redhat.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: Mon, 7 Dec 2020 10:28:32 +0000 (UTC) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2012071021390.53970@www.lameter.com> (raw)
In-Reply-To: <7812B8AB-7D26-4148-8C8C-E1241A1FC8CD@oracle.com>
Looking at librdmacm/rdma_getaddrinfo():
It seems that the call to the IBACM via ucma_ib_resolve() is only done
after a regular getaddrinfo() was run. Is IBACM truly able to provide
address resolution or is it just some strange after processing if the main
resolution attempt fails?
AFACIT ucma_resolve() should run before getaddrinfo()?
Or is there some magic in getaddrinfo() that actually does another call to
the IBACM daemon?
What is also confusing is that the path record determination is part of
getaddrinfo() as well. So both the address and route lookup end up in
getaddrinfo(). Is IB therefore using the kernel to do the lookups?
next prev parent reply other threads:[~2020-12-07 10:29 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
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 [this message]
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=alpine.DEB.2.22.394.2012071021390.53970@www.lameter.com \
--to=cl@linux.com \
--cc=haakon.bugge@oracle.com \
--cc=honli@redhat.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