From: Leon Romanovsky <leon@kernel.org>
To: Doug Ledford <dledford@redhat.com>, Jason Gunthorpe <jgg@mellanox.com>
Cc: Leon Romanovsky <leonro@mellanox.com>,
RDMA mailing list <linux-rdma@vger.kernel.org>,
Erez Alfasi <ereza@mellanox.com>
Subject: [PATCH rdma-next v3 0/4] ODP information and statistics
Date: Wed, 16 Oct 2019 09:23:04 +0300 [thread overview]
Message-ID: <20191016062308.11886-1-leon@kernel.org> (raw)
From: Leon Romanovsky <leonro@mellanox.com>
Changelog:
v3:
* Implement batch count of "invalidataions".
* "prefetched" ounter is dropped, will be separated to two separate counters (RQ/SQ)
later once Jason's ODP rework will be finished.
v2: https://lore.kernel.org/linux-rdma/20191006155139.30632-1-leon@kernel.org
* Since umems can disappear during rereg flow and the fact that we
are not locking its during our counter usage (uverbs prevents this
by holding the uobject write lock), expose possible race bugs. Move
the counters into mlx5_ib_mr to avoid racing bugs (related patches
- #1, #3 & #4).
* Fix page invalidation counting (Patch #1).
* Make the code more elegant by defining fill_function type and use it
within res_common_{dumpit, doit} (Patch #2).
* Put an ODP implicit indicator within mlx5 reg MR operation,
indicating when a given MR is ODP implicit registered and use
its indication when dumping ODP type.
* Since the counters has been moved to mlx5_ib_mr, the ODP stats are now
filled with internal to mlx5 driver function. Remove the fill_odp_stats
device operation from the reason mentioned above.
v1: https://lore.kernel.org/linux-rdma/20190830081612.2611-1-leon@kernel.org
* Dropped umem patch, because it doesn't follow our IB model, where
UMEM is driver object and ib_core object (Jason).
* Removed the ODP type indicator from ib_umem_odp not needed after
commit fd7dbf035edc ("RDMA/odp: Make it clearer when a umem is an implicit ODP umem")
* Since umems are not part of core MR (from the reason mentioned
above) there is no way to access the odp type as was previously done via nldev
(old patch #3). Instead, patch #4 is adding mlx5 implementation for fill_res_entry
and dumping ODP type as part of the driver table entry, as its driver details.
* Counter types are now atomic64_t instead of u64.
v0: https://lore.kernel.org/linux-rdma/20190807103403.8102-1-leon@kernel.org
-----------------------------------------------------------------------------
Hi,
This series from Erez refactors exposes ODP type information (explicit,
implicit) and statistics through netlink interface.
Thanks
Erez Alfasi (4):
IB/mlx5: Introduce ODP diagnostic counters
RDMA/nldev: Allow different fill function per resource
RDMA/mlx5: Return ODP type per MR
RDMA/nldev: Provide MR statistics
drivers/infiniband/core/device.c | 1 +
drivers/infiniband/core/nldev.c | 98 ++++++++++++++++++++-------
drivers/infiniband/hw/mlx5/Makefile | 2 +-
drivers/infiniband/hw/mlx5/main.c | 3 +
drivers/infiniband/hw/mlx5/mlx5_ib.h | 9 +++
drivers/infiniband/hw/mlx5/odp.c | 17 +++++
drivers/infiniband/hw/mlx5/restrack.c | 90 ++++++++++++++++++++++++
include/rdma/ib_verbs.h | 12 ++++
include/rdma/restrack.h | 6 ++
9 files changed, 212 insertions(+), 26 deletions(-)
create mode 100644 drivers/infiniband/hw/mlx5/restrack.c
--
2.20.1
next reply other threads:[~2019-10-16 6:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 6:23 Leon Romanovsky [this message]
2019-10-16 6:23 ` [PATCH rdma-next v3 1/4] IB/mlx5: Introduce ODP diagnostic counters Leon Romanovsky
2019-10-16 6:23 ` [PATCH rdma-next v3 2/4] RDMA/nldev: Allow different fill function per resource Leon Romanovsky
2019-10-16 6:23 ` [PATCH rdma-next v3 3/4] RDMA/mlx5: Return ODP type per MR Leon Romanovsky
2019-10-16 6:23 ` [PATCH rdma-next v3 4/4] RDMA/nldev: Provide MR statistics Leon Romanovsky
2019-10-22 18:41 ` Jason Gunthorpe
2019-10-22 18:53 ` [PATCH rdma-next v3 0/4] ODP information and statistics Jason Gunthorpe
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=20191016062308.11886-1-leon@kernel.org \
--to=leon@kernel.org \
--cc=dledford@redhat.com \
--cc=ereza@mellanox.com \
--cc=jgg@mellanox.com \
--cc=leonro@mellanox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).