linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Jason Gunthorpe <jgg@mellanox.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Israel Rukshin <israelr@mellanox.com>,
	linux-rdma@vger.kernel.org, dledford@redhat.com,
	maxg@mellanox.com, sergeygo@mellanox.com,
	Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH] IB/iser: Remove support for FMR memory registration
Date: Wed, 13 May 2020 10:18:55 +0300	[thread overview]
Message-ID: <20200513071855.GQ4814@unreal> (raw)
In-Reply-To: <b9dab6bf-d1b8-40c0-63ba-09eb3f4882f5@grimberg.me>

On Tue, May 12, 2020 at 05:53:34PM -0700, Sagi Grimberg wrote:
>
> > > > > > > FMR is not supported on most recent RDMA devices (that use fast memory
> > > > > > > registration mechanism). Also, FMR was recently removed from NFS/RDMA
> > > > > > > ULP.
> > > > > > >
> > > > > > > Signed-off-by: Israel Rukshin <israelr@mellanox.com>
> > > > > > > Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
> > > > > > >   drivers/infiniband/ulp/iser/iscsi_iser.h     |  79 +----------
> > > > > > >   drivers/infiniband/ulp/iser/iser_initiator.c |  19 ++-
> > > > > > >   drivers/infiniband/ulp/iser/iser_memory.c    | 188 ++-------------------------
> > > > > > >   drivers/infiniband/ulp/iser/iser_verbs.c     | 126 +++---------------
> > > > > > >   4 files changed, 40 insertions(+), 372 deletions(-)
> > > > > >
> > > > > > Can we do an extra step and remove FMR from srp too?
> > > > >
> > > > > Which HCA's will be affected by removing FMR support? Or in other words,
> > > > > when did (Mellanox) HCA's start supporting fast memory registration? I'm
> > > > > asking this because there is a tradition in the Linux kernel not to
> > > > > remove support for old hardware unless it is pretty sure that nobody is
> > > > > using that hardware anymore.
> > > >
> > > > We haven't entirely been following that in RDMA.. More like when
> > > > people can't test any more it can go.
> > > >
> > > > For FMR the support was dropped in newer HW so AFAIK, nobody tests
> > > > this and it just stands in the way of making FRWR work properly.
> > > >
> > > > Do the ULPs stop working or do they just run slower with some regular
> > > > MR flow?
> > >
> > > I'm not sure. I do not have access to RDMA adapters that do not support
> > > FRWR.
> > >
> > > A possible test is to check on websites for used products whether old
> > > RDMA adapters are still available. Is the InfiniHost adapter one of the
> > > adapters that supports FMR? It seems like that adapter is still easy to
> > > find.
> >
> > I don't know - AFAIK nobody does any testing on those cards any
> > more, and doesn't test the ULPs either.
> >
> > I know Leon has pushed to remove the mthca driver in the past.  At one
> > point there was a suggestion that drivers that do not support FRWR
> > should be dropped, but I don't remember if mthca is the last one or
> > not.
> >
> > There has been a big push to purge useless old stuff, look at the
> > entire arch removals for instance. The large RDMA drivers fall under
> > the same logic, IMHO.
>
> I think we should remove this support, if there is a user of this
> somewhere he can safely use iscsi. Let alone that iser uses the fmr
> pools which leaves rkeys exposed for caching purposes. So I'd much
> rather remove it than trying to fix it.

Agree, given the fact that no one is even going to try to fix.

We don't see new contributors in this community who are not affiliated
with RDMA companies and they are not testing and have no plans to test FMR.

I feel that we can't even say if FMR and old cards work :).

Thanks

  reply	other threads:[~2020-05-13  7:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-12 16:08 [PATCH] IB/iser: Remove support for FMR memory registration Israel Rukshin
2020-05-12 17:16 ` Leon Romanovsky
2020-05-12 17:53   ` Max Gurtovoy
2020-05-12 20:09   ` Bart Van Assche
2020-05-12 20:13     ` Jason Gunthorpe
2020-05-12 20:27       ` Bart Van Assche
2020-05-12 23:06         ` Jason Gunthorpe
2020-05-13  0:53           ` Sagi Grimberg
2020-05-13  7:18             ` Leon Romanovsky [this message]
2020-05-13 16:44               ` Dennis Dalessandro
2020-05-13 18:43                 ` Leon Romanovsky
2020-05-13 19:49                   ` Bart Van Assche
2020-05-13  8:43     ` Max Gurtovoy
2020-05-13 11:29       ` Tom Talpey
     [not found]       ` <0C22D41B-89CD-4B2D-B514-8EA06F2233D7@cloudlinux.com>
2020-05-14 10:50         ` Max Gurtovoy
2020-05-14 13:50           ` Tom Talpey
2020-05-17  8:35         ` Sagi Grimberg
2020-05-17 14:55           ` Alexey Lyashkov
2020-05-18  7:16           ` Christoph Hellwig
2020-05-13  0:56 ` Sagi Grimberg

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=20200513071855.GQ4814@unreal \
    --to=leon@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=chuck.lever@oracle.com \
    --cc=dledford@redhat.com \
    --cc=israelr@mellanox.com \
    --cc=jgg@mellanox.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=maxg@mellanox.com \
    --cc=sagi@grimberg.me \
    --cc=sergeygo@mellanox.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;
as well as URLs for NNTP newsgroup(s).