public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Gal Pressman <galpress@amazon.com>
Cc: Leon Romanovsky <leonro@nvidia.com>,
	Doug Ledford <dledford@redhat.com>,
	linux-rdma@vger.kernel.org
Subject: Re: [PATCH for-next] RDMA/nldev: Add parent bdf to device information dump
Date: Sun, 8 Nov 2020 19:49:35 -0400	[thread overview]
Message-ID: <20201108234935.GC244516@ziepe.ca> (raw)
In-Reply-To: <cd3f2926-0491-8540-d6b1-534014190bae@amazon.com>

On Sun, Nov 08, 2020 at 03:03:45PM +0200, Gal Pressman wrote:
> On 05/11/2020 22:00, Jason Gunthorpe wrote:
> > On Tue, Nov 03, 2020 at 05:45:26PM +0200, Gal Pressman wrote:
> >> On 03/11/2020 16:22, Jason Gunthorpe wrote:
> >>> On Tue, Nov 03, 2020 at 04:11:19PM +0200, Gal Pressman wrote:
> >>>> On 03/11/2020 15:57, Leon Romanovsky wrote:
> >>>>> On Tue, Nov 03, 2020 at 09:45:22AM -0400, Jason Gunthorpe wrote:
> >>>>>> On Tue, Nov 03, 2020 at 03:26:27PM +0200, Gal Pressman wrote:
> >>>>>>> Add the ability to query the device's bdf through rdma tool netlink
> >>>>>>> command (in addition to the sysfs infra).
> >>>>>>>
> >>>>>>> In case of virtual devices (rxe/siw), the netdev bdf will be shown.
> >>>>>>
> >>>>>> Why? What is the use case?
> >>>>>
> >>>>> Right, and why isn't netdev (RDMA_NLDEV_ATTR_NDEV_NAME) enough?
> >>>>
> >>>> When taking system topology into consideration you need some way to pair the
> >>>> ibdev and bdf, especially when working with multiple devices.
> >>>> The netdev name doesn't exist on devices with no netdevs (IB, EFA).
> >>>
> >>> You are supposed to use sysfs
> >>>
> >>> /sys/class/infiniband/ibp0s9/device
> >>>
> >>> Should always be the physical device
> >>>
> >>>> Why rdma tool? Because it's more intuitive than sysfs.
> >>>
> >>> But we generally don't put this information into netlink BDF is just
> >>> the start, you need all the other topology information to make sense
> >>> of it, and all that is in sysfs only already
> >>
> >> As the commit message says, it's in addition to the device sysfs.
> >>
> >> Many (if not most) of the existing rdma netlink commands are duplicates of some
> >> sysfs entries, but show it in a more "modern" way.
> >> I'm not convinced that bdf should be treated differently.
> > 
> > Why did you call it BDF anyhow? it has nothing to do with PCI BDF
> > other than it happens to be the PDF for PCI devices. Netdev called
> > this bus_info
> 
> Are there non pci devices in the subsystem?

Yes, HNS uses non-pci devices

> I can rename to a more fitting name, will change to bus_info unless
> someone has a better idea.

The thing is, is is still useless. You have to consult sysfs to
understand what bus it is scoped on to do anything further with
it. Can't just assume it is PCI.

Jason

  parent reply	other threads:[~2020-11-08 23:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-03 13:26 [PATCH for-next] RDMA/nldev: Add parent bdf to device information dump Gal Pressman
2020-11-03 13:31 ` Parav Pandit
2020-11-03 13:45 ` Jason Gunthorpe
2020-11-03 13:57   ` Leon Romanovsky
2020-11-03 14:11     ` Gal Pressman
2020-11-03 14:22       ` Jason Gunthorpe
2020-11-03 15:45         ` Gal Pressman
2020-11-05 20:00           ` Jason Gunthorpe
2020-11-08 13:03             ` Gal Pressman
2020-11-08 14:36               ` Parav Pandit
2020-11-08 23:49               ` Jason Gunthorpe [this message]
2020-11-09  5:09                 ` Leon Romanovsky
2020-11-09  9:03                   ` Gal Pressman
2020-11-09 11:55                     ` Leon Romanovsky
2020-11-09 12:27                       ` Gal Pressman
2020-11-09 12:32                         ` Leon Romanovsky
2020-11-09 12:47                           ` Gal Pressman
2020-11-09 13:02                             ` Leon Romanovsky
2020-11-09 13:52                               ` Gal Pressman
2020-11-09 14:12                                 ` Leon Romanovsky
2020-11-09  9:03                 ` Gal Pressman
2020-11-09 17:57                   ` Jason Gunthorpe
2020-11-10  7:49                     ` Gal Pressman
2020-11-10 13:41                       ` Jason Gunthorpe
2020-11-10 13:54                         ` 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=20201108234935.GC244516@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=dledford@redhat.com \
    --cc=galpress@amazon.com \
    --cc=leonro@nvidia.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