All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@mellanox.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Jiri Pirko <jiri@resnulli.us>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"oss-drivers@netronome.com" <oss-drivers@netronome.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Parav Pandit <parav@mellanox.com>
Subject: Re: [PATCH net-next 4/8] devlink: allow subports on devlink PCI ports
Date: Tue, 5 Mar 2019 01:30:19 +0000	[thread overview]
Message-ID: <20190305013013.GK8627@mellanox.com> (raw)
In-Reply-To: <20190304170320.10e40255@cakuba.netronome.com>

On Mon, Mar 04, 2019 at 05:03:20PM -0800, Jakub Kicinski wrote:

> > Don't we already have devlink instances for every mlx5 physical port
> > and VF as they are unique PCI functions?
> 
> That's a very NIC-centric view of the world, though.  Equating devlink
> instances to ports, and further to PCI devices.  Its fundamentally
> different from what switches and some NICs do, where all ports are under
> single devlink instance.

I think, as a practical matter, it is a bit hard to recombine an asic
that presents multiple PCI BDFs into a single SW object. It is tricky
to give stable labels to things, to leave gaps to allow for uncertain
discovey, to co-ordinate between multiple struct pci_device drivers
probe functions, etc.

And at least with devlink, if you have a object layer that is broader
then PCI BDF, how do the devlink commands work? Are all BDFs just an
alias for this hidden super object?

Do any drivers attempt to provide single instant made up of merged
BDFs?

In other words, is a PCI BDF really the largest granularity that
devlink can address today?

At least in RDMA we have drivers doing all combinations of this:
multiple ports per BDF, one port per BDF, and one composite RDMA
device formed by combining multiple BDFs worth of ports together.

> > > You guys come from the RDMA side of the world, with which I'm less
> > > familiar, and the soft bus + spawning devices seems to be a popular
> > > design there.  Could you describe the advantages of that model for 
> > > the sake of the netdev-only folks? :)  
> > 
> > I don't think we do this in RDMA at all yet, or maybe I'm not sure
> > what you are thinking of?
> 
> Mm.. I caught an Intel patch set recently which was talking about buses
> and spawning devices.  It must have been a different kettle of fish.

That sounds like scalable iov..

Jason

  reply	other threads:[~2019-03-05  1:31 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26 18:24 [PATCH net-next 0/8] devlink: add PF and VF port flavours Jakub Kicinski
2019-02-26 18:24 ` [PATCH net-next 1/8] nfp: split devlink port init from registration Jakub Kicinski
2019-02-26 18:24 ` [PATCH net-next 2/8] devlink: add PF and VF port flavours Jakub Kicinski
2019-02-27 12:16   ` Jiri Pirko
2019-03-04  4:59     ` Parav Pandit
2019-03-04  7:30       ` Jiri Pirko
2019-03-20 17:29         ` Abodunrin, Akeem G
2019-03-21 12:26           ` Jiri Pirko
2019-02-27 12:23   ` Jiri Pirko
2019-02-27 12:41     ` Jiri Pirko
2019-02-27 17:23       ` Jakub Kicinski
2019-02-27 20:17         ` Jiri Pirko
2019-02-27 22:42           ` Jakub Kicinski
2019-02-28  8:44             ` Jiri Pirko
2019-02-28 16:08               ` Jakub Kicinski
2019-02-28 16:24             ` David Ahern
2019-02-26 18:24 ` [PATCH net-next 3/8] nfp: register devlink ports of all reprs Jakub Kicinski
2019-02-26 18:24 ` [PATCH net-next 4/8] devlink: allow subports on devlink PCI ports Jakub Kicinski
2019-02-27 12:37   ` Jiri Pirko
2019-02-27 18:30     ` Jakub Kicinski
2019-02-28  8:56       ` Jiri Pirko
2019-02-28 13:32         ` Jiri Pirko
2019-02-28 16:24         ` Jakub Kicinski
2019-03-01  7:25           ` Jiri Pirko
2019-03-01 16:04             ` Jakub Kicinski
2019-03-01 16:20               ` Jiri Pirko
2019-03-04 16:15       ` Jason Gunthorpe
2019-03-05  1:03         ` Jakub Kicinski
2019-03-05  1:30           ` Jason Gunthorpe [this message]
2019-03-05  2:11             ` Jakub Kicinski
2019-03-05 22:11               ` Jason Gunthorpe
2019-03-04  5:00     ` Parav Pandit
2019-02-26 18:24 ` [PATCH net-next 5/8] nfp: switch to devlink_port_get_phys_port_name() Jakub Kicinski
2019-02-26 18:24 ` [PATCH net-next 6/8] devlink: introduce port's peer netdevs Jakub Kicinski
2019-02-27 13:08   ` Jiri Pirko
2019-02-27 18:47     ` Jakub Kicinski
2019-02-28  9:00       ` Jiri Pirko
2019-02-28 16:36         ` Jakub Kicinski
2019-03-01  7:37           ` Jiri Pirko
2019-03-01 16:05             ` Jakub Kicinski
2019-03-04  5:07     ` Parav Pandit
2019-02-26 18:24 ` [PATCH net-next 7/8] nfp: expose PF " Jakub Kicinski
2019-02-26 18:24 ` [PATCH net-next 8/8] devlink: fix kdoc Jakub Kicinski
2019-02-27 13:13   ` Jiri Pirko

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=20190305013013.GK8627@mellanox.com \
    --to=jgg@mellanox.com \
    --cc=davem@davemloft.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=parav@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.