netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@mellanox.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Doug Ledford <dledford@redhat.com>,
	linux-rdma@vger.kernel.org,
	Michael Guralnik <michaelgur@mellanox.com>,
	netdev@vger.kernel.org, Saeed Mahameed <saeedm@mellanox.com>,
	Yishai Hadas <yishaih@mellanox.com>
Subject: Re: [PATCH rdma-next 0/4] Introduce dynamic UAR allocation mode
Date: Wed, 18 Mar 2020 11:39:03 -0300	[thread overview]
Message-ID: <20200318143903.GN13183@mellanox.com> (raw)
In-Reply-To: <20200318142455.GC126814@unreal>

On Wed, Mar 18, 2020 at 04:24:55PM +0200, Leon Romanovsky wrote:
> > > I'm ok with this approach because it helps us to find those dead
> > > paths, but have last question, shouldn't this be achieved with
> > > proper documentation of every flag instead of adding CONFIG_..?
> >
> > How do you mean?
> >
> > The other half of this idea is to disable obsolete un tested code to
> > avoid potential bugs. Which requires CONFIG_?
> 
> The second part is achievable by distros when they will decide to
> support starting from version X. The same decision is not so easy
> to do in the upstream.

Upstream will probably carry the code for a long, long time, that
doesn't mean the distros don't get value by using a shorter time
window

> Let's take as an example this feature. It will be set as default from
> rdma-core v29 and the legacy code will be guarded by
> "if (CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION >= 29)". When will change
> CONFIG_INFINIBAND_MIN_RDMA_CORE_VERSION to be above 29? So we will
> delete such legacy code.

First the distros will decide in their own kconfigs where they want to
set the value.

Then the upstream kernel will decide some default value

Then maybe we could talk about lowest values when enough of the user
community uses a higher value

Jason

  reply	other threads:[~2020-03-18 14:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18 12:43 [PATCH rdma-next 0/4] Introduce dynamic UAR allocation mode Leon Romanovsky
2020-03-18 12:43 ` [PATCH mlx5-next 4/4] IB/mlx5: Move to fully dynamic UAR mode once user space supports it Leon Romanovsky
2020-03-18 23:38   ` Saeed Mahameed
2020-03-19  5:55     ` Leon Romanovsky
2020-03-18 12:54 ` [PATCH rdma-next 0/4] Introduce dynamic UAR allocation mode Jason Gunthorpe
2020-03-18 13:14   ` Leon Romanovsky
2020-03-18 13:21     ` Jason Gunthorpe
2020-03-18 13:56       ` Leon Romanovsky
2020-03-18 14:00         ` Jason Gunthorpe
2020-03-18 14:09           ` Leon Romanovsky
2020-03-18 14:12             ` Jason Gunthorpe
2020-03-18 14:24               ` Leon Romanovsky
2020-03-18 14:39                 ` Jason Gunthorpe [this message]
2020-03-18 17:07                   ` Leon Romanovsky

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=20200318143903.GN13183@mellanox.com \
    --to=jgg@mellanox.com \
    --cc=dledford@redhat.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=michaelgur@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=yishaih@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).