From: Haakon Bugge <haakon.bugge@oracle.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Anand Khoje <anand.a.khoje@oracle.com>,
OFED mailing list <linux-rdma@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dledford@redhat.com" <dledford@redhat.com>,
"jgg@ziepe.ca" <jgg@ziepe.ca>
Subject: Re: [PATCH v2 3/3] IB/core: Obtain subnet_prefix from cache in IB devices
Date: Thu, 3 Jun 2021 10:36:44 +0000 [thread overview]
Message-ID: <7312F593-FF71-4EEB-9D4A-6F32A4AC7AE9@oracle.com> (raw)
In-Reply-To: <YLisCgBLu9pD1qSw@unreal>
> On 3 Jun 2021, at 12:16, Leon Romanovsky <leon@kernel.org> wrote:
>
> On Thu, Jun 03, 2021 at 09:29:32AM +0000, Haakon Bugge wrote:
>>
>>
>>> On 3 Jun 2021, at 11:07, Leon Romanovsky <leon@kernel.org> wrote:
>>>
>>> On Thu, Jun 03, 2021 at 12:20:24PM +0530, Anand Khoje wrote:
>>>> ib_query_port() calls device->ops.query_port() to get the port
>>>> attributes. The method of querying is device driver specific.
>>>> The same function calls device->ops.query_gid() to get the GID and
>>>> extract the subnet_prefix (gid_prefix).
>>>>
>>>> The GID and subnet_prefix are stored in a cache. But they do not get
>>>> read from the cache if the device is an Infiniband device. The
>>>> following change takes advantage of the cached subnet_prefix.
>>>> Testing with RDBMS has shown a significant improvement in performance
>>>> with this change.
>>>>
>>>> The function ib_cache_is_initialised() is introduced because
>>>> ib_query_port() gets called early in the stage when the cache is not
>>>> built while reading port immutable property.
>>>>
>>>> In that case, the default GID still gets read from HCA for IB link-
>>>> layer devices.
>>>>
>>>> Fixes: fad61ad ("IB/core: Add subnet prefix to port info")
>>>> Signed-off-by: Anand Khoje <anand.a.khoje@oracle.com>
>>>> Signed-off-by: Haakon Bugge <haakon.bugge@oracle.com>
>>>> ---
>>>> drivers/infiniband/core/cache.c | 7 ++++++-
>>>> drivers/infiniband/core/device.c | 9 +++++++++
>>>> include/rdma/ib_cache.h | 6 ++++++
>>>> include/rdma/ib_verbs.h | 6 ++++++
>>>> 4 files changed, 27 insertions(+), 1 deletion(-)
>>>
>>> Can you please help me to understand how cache is updated?
>>>
>>> There are a lot of calls to ib_query_port() and I wonder how callers can
>>> get new GID after it was changed in already initialized cache.
>>
>> The cache is initialized when it is created, just before the bit IB_PORT_CACHE_INITIALIZED is set in flags.
>>
>> After commit d58c23c92548 ("IB/core: Only update PKEY and GID caches on respective events"), the GID portion of the cache is updated when a IB_EVENT_GID_CHANGE event is received.
>>
>> Before said commit, it was updated on any event.
>
> This part is clear to me, the missing piece is to understand what will
> happen if cache and GID are not in sync because of asynchronous nature of
> events.
The calls to ib_query_port() are asynchronous with GID change. Consider the time line:
Time HCA cache
t0 GIDa GIDa
t1
t2 GIDb GIDa
t3
t4 GIDb GIDb
t5
Prior to this commit, if ib_query_port() was called at t1 or at t3, two different GIDs would be retrieved.
With this commit, if ib_query_port() was called at t3 or t5, two different GIDs would be retrieved.
The scenario is the same, only skewed in time.
Thxs, Håkon
next prev parent reply other threads:[~2021-06-03 10:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 6:50 [PATCH v2 0/3] IB/core: Obtaining " Anand Khoje
2021-06-03 6:50 ` [PATCH v2 1/3] IB/core: Removed port validity check from ib_get_cached_subnet_prefix Anand Khoje
2021-06-03 8:54 ` Leon Romanovsky
2021-06-03 6:50 ` [PATCH v2 2/3] IB/core: Shuffle locks in ib_port_data to save memory Anand Khoje
2021-06-03 8:55 ` Leon Romanovsky
2021-06-03 6:50 ` [PATCH v2 3/3] IB/core: Obtain subnet_prefix from cache in IB devices Anand Khoje
2021-06-03 9:07 ` Leon Romanovsky
2021-06-03 9:29 ` Haakon Bugge
2021-06-03 10:16 ` Leon Romanovsky
2021-06-03 10:36 ` Haakon Bugge [this message]
2021-06-03 12:10 ` Mark Zhang
2021-06-03 12:50 ` Haakon Bugge
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=7312F593-FF71-4EEB-9D4A-6F32A4AC7AE9@oracle.com \
--to=haakon.bugge@oracle.com \
--cc=anand.a.khoje@oracle.com \
--cc=dledford@redhat.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®