From: Jason Gunthorpe <jgg@ziepe.ca>
To: Dennis Dalessandro <dennis.dalessandro@intel.com>
Cc: Haim Boozaglo <haimbo@mellanox.com>,
Leon Romanovsky <leon@kernel.org>,
linux-rdma@vger.kernel.org
Subject: Re: "ibstat -l" displays CA device list in an unsorted order
Date: Thu, 27 Feb 2020 11:26:28 -0400 [thread overview]
Message-ID: <20200227152628.GH31668@ziepe.ca> (raw)
In-Reply-To: <b5a619bc-582d-908a-6c6e-5df5bbe4b4b2@intel.com>
On Thu, Feb 27, 2020 at 09:55:23AM -0500, Dennis Dalessandro wrote:
> > > I can just sort the list at the time of insertion of each node.
> >
> > I'd rather not have to pay the sorting penalty for all users, it seems
> > only a few command line tools need the sort
>
> Should we really go out on limb here and assume it's just a few CLI tools?
> What about all the sysadmin type scripts out there? We aren't having a good
> track record not breaking user space lately.
'sysadmin scripts' can't view the umad list without going through a
cli tool - so sorting the cli tools that show lists of device things
will take care of it.
verbs is has always been unsorted, so things like ibv_devinfo
return in creation order. (which I think is a different random
ordering than it used to be)
This isn't the first time someone has complated about sorting, I
recall there was a complaint about ibv_get_device_list() too, but it
was never sorted. It just happened that sometimes it would be sorted
by some luck.
At least in the umad case it was actually always sorted before.
I think we should also sort ibv_devinfo too while we are here.
> Is the sorting penalty really going to be that bad? It's not like we will
> have a large number of devices that sorting should really be an issue I
> wouldn't think.
There are configurations where we have a large number of devices.
Jason
next prev parent reply other threads:[~2020-02-27 15:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 18:06 "ibstat -l" displays CA device list in an unsorted order Haim Boozaglo
2020-02-24 19:41 ` Jason Gunthorpe
2020-02-25 8:25 ` Haim Boozaglo
2020-02-26 13:43 ` Jason Gunthorpe
2020-02-26 13:57 ` Leon Romanovsky
2020-02-26 17:09 ` Jason Gunthorpe
2020-02-27 7:48 ` Haim Boozaglo
2020-02-27 12:49 ` Leon Romanovsky
2020-02-27 12:57 ` Vladimir Koushnir
2020-02-27 13:59 ` Leon Romanovsky
2020-02-27 13:33 ` Jason Gunthorpe
2020-02-27 14:55 ` Dennis Dalessandro
2020-02-27 15:26 ` Jason Gunthorpe [this message]
2020-02-25 7:48 ` Leon Romanovsky
2020-02-25 8:36 ` Haim Boozaglo
2020-02-25 9:18 ` Leon Romanovsky
2020-02-25 17:18 ` Jens Domke
2020-02-25 19:43 ` Leon Romanovsky
2020-02-26 13:42 ` Dennis Dalessandro
2020-02-26 13:56 ` 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=20200227152628.GH31668@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=dennis.dalessandro@intel.com \
--cc=haimbo@mellanox.com \
--cc=leon@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;
as well as URLs for NNTP newsgroup(s).