linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Gal Pressman <galpress@amazon.com>
Cc: Dennis Dalessandro <dennis.dalessandro@intel.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	Jason Gunthorpe <jgg@ziepe.ca>, Honggang LI <honli@redhat.com>
Subject: Re: RDMA device renames and node description
Date: Wed, 19 Feb 2020 17:10:19 +0200	[thread overview]
Message-ID: <20200219151019.GN15239@unreal> (raw)
In-Reply-To: <67915d24-149a-e940-1f0b-a173eb4aca84@amazon.com>

On Wed, Feb 19, 2020 at 04:35:40PM +0200, Gal Pressman wrote:
> On 19/02/2020 16:14, Dennis Dalessandro wrote:
> > On 2/19/2020 2:11 AM, Leon Romanovsky wrote:
> >> On Tue, Feb 18, 2020 at 12:11:47PM -0500, Dennis Dalessandro wrote:
> >>> On 2/18/2020 9:04 AM, Leon Romanovsky wrote:
> >>>> On Fri, Feb 14, 2020 at 01:13:53PM -0500, Dennis Dalessandro wrote:
> >> ABI breakage is a strong word, luckily enough it is not defined at all.
> >> We never considered dmesg prints, device names, device ordering as an
> >> ABI. You can't rely on debug features too, they can disappear too.
> >
> > Agree, it is a strong word and we can call it what you want. The point is you
> > should be able to rely on the node description not being changed out from under
> > you unnecessarily though. We aren't talking about a debug feature here but a
> > core feature to real world deployments.
> >
> > Could you envision a patch to a user space library that just changes a devices
> > hostname to something that was HW specific because it makes scripting easier? I
> > contend that in some cases the node description remaining constant is just as
> > important.
> >
> >> So the bottom line, the expectation that distro should fix all broken
> >> software before enabling device renaming and their bugs are not excuse
> >> to declare ABI breakage.
> >
> > Again, call it what you want, but you can't deny this change to force the rename
> > by default has not broken things. For the record I'm not even talking about PSM2
> > here. There are other, more far reaching implications.
>
> It's not just PSM2, it broke our libfabric provider and apparently MVAPICH as well:
> http://mailman.cse.ohio-state.edu/pipermail/mvapich-discuss/2020-January/006960.html
>
> Regarding the issue you described, why not disable the rename on the upgrade
> path and only enable it for fresh installations?

Good suggestion, at least in theory, it can be done for the RPMs. Just
need to be careful to distinguish upgrades from pre-v24 versions and
post-v24 versions.

Thanks

  reply	other threads:[~2020-02-19 15:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14 18:13 RDMA device renames and node description Dennis Dalessandro
2020-02-18 14:04 ` Leon Romanovsky
2020-02-18 17:11   ` Dennis Dalessandro
2020-02-18 20:08     ` Jason Gunthorpe
2020-02-19  7:11     ` Leon Romanovsky
2020-02-19 14:14       ` Dennis Dalessandro
2020-02-19 14:35         ` Gal Pressman
2020-02-19 15:10           ` Leon Romanovsky [this message]
2020-02-19 16:54           ` Jason Gunthorpe
2020-02-19 14:48         ` Leon Romanovsky
2020-02-19 15:34           ` Dennis Dalessandro
2020-02-19 16:58         ` Jason Gunthorpe
2020-02-19 19:35           ` Dennis Dalessandro
2020-02-19 23:18             ` Ira Weiny
2020-02-20  2:26               ` Dennis Dalessandro

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=20200219151019.GN15239@unreal \
    --to=leon@kernel.org \
    --cc=dennis.dalessandro@intel.com \
    --cc=galpress@amazon.com \
    --cc=honli@redhat.com \
    --cc=jgg@ziepe.ca \
    --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).