Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
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: Sat, 5 Dec 2020 11:50:30 +0000 (UTC)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2012051145380.41487@www.lameter.com> (raw)
In-Reply-To: <7812B8AB-7D26-4148-8C8C-E1241A1FC8CD@oracle.com>

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

On Fri, 4 Dec 2020, Håkon Bugge wrote:

> >> Nop, the kernel falls back and uses the neighbour cache instead.
> >
> > But ib_acme hangs? The main issue here is what the user space app does.
> > And we need ibacm to cache user space address resolutions.
>
> I got the impression that you are debugging this with Honggang. If you want me to help, I need, to start with, an strace of ib_acme and ditto of ibacm.

Ok will do that. Do you have access to the RH case on this one?

> >>>> 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.
> >>>
> >>> That is working if you want to resolve only the IP addresses of the IB
> >>> interfaces on the client and target. None else.
> >>
> >> That is why it is called IBacm, right?
> >
> > Huh? IBACM is an address resolution service for IB. Somehow that only
> > includes addresses of hosts running IBACM?
>
> Yes. As Honggang explained, ibacmn's address resolution protocol is
> based on IB multicast, as such, the peer must have ibacm running in
> order to send a unicast response back with the L2 addr.

What is the point of the route_prot and addr_prot then?

> >>> Here is the description of ibacms function from the sources:
> >>>
> >>> "Conceptually, the ibacm service implements an ARP like protocol and
> >>> either uses IB multicast records to construct path record data or queries
> >>> the SA directly, depending on the selected route protocol. By default, the
> >>> ibacm services uses and caches SA path record queries."
> >>>
> >>> SA queries dont work. So its broken and cannot talk to the SM.
> >>
> >> Why do you say that? It works all the time for me which uses "sa" as "route_prot".
> >
> > Not here and not in the tests that RH ran to verify the issue.
> >
> > "route_prot" set to "sa" is the default config for the Redhat release of
> > IBACM.
> >
> > However, the addr_prot is set to  "acm" by default. I set it to "sa" with
> > no effect.
>
> OK. Understood. As stated above, let me know if you want me to debug this.

Well whats the point to debug this if its only doing address resolution
via multicast and not via the SA?

Is there a particular issue with usiing the SA? The route information may
contain process specific information?

  reply	other threads:[~2020-12-05 18:42 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 [this message]
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=alpine.DEB.2.22.394.2012051145380.41487@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