RE: [PATCH net-next 4/8] devlink: allow subports on devlink PCI ports

Parav Pandit
2019-03-04T05:00:50Z

> -----Original Message-----
> From: Jiri Pirko <jiri@resnulli.us>
> Sent: Wednesday, February 27, 2019 6:38 AM
> To: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: davem@davemloft.net; oss-drivers@netronome.com;
> netdev@vger.kernel.org; Parav Pandit <parav@mellanox.com>; Jason
> Gunthorpe <jgg@mellanox.com>
> Subject: Re: [PATCH net-next 4/8] devlink: allow subports on devlink PCI
> ports
>
> Tue, Feb 26, 2019 at 07:24:32PM CET, jakub.kicinski@netronome.com wrote:
> >PCI endpoint corresponds to a PCI device, but such device can have one
> >more more logical device ports associated with it.
> >We need a way to distinguish those. Add a PCI subport in the dumps and
> >print the info in phys_port_name appropriately.
> >
> >This is not equivalent to port splitting, there is no split group. It's
> >just a way of representing multiple netdevs on a single PCI function.
> >
> >Note that the quality of being multiport pertains only to the PCI
> >function itself. A PF having multiple netdevs does not mean that its
> >VFs will also have multiple, or that VFs are associated with any
> >particular port of a multiport VF.
> >
>
> We've been discussing the problem of subport (we call it "subfunction"
> or "SF") for some time internally. Turned out, this is probably harder task to
> model. Please prove me wrong.
>
> The nature of VF makes it a logically separate entity. It has a separate PCI
> address, it should therefore have a separate devlink instance.
> You can pass it through to VM, then the same devlink instance should be
> created inside the VM and disappear from the host.
>
> SF (or subport) feels similar to that. Basically it is exactly the same thing as
> VF, only does reside under PF PCI function.
>
> That is why I think, for sake of consistency, it should have a separate devlink
> entity as well. The problem is correct sysfs modelling and devlink handle
> derived from that. Parav is working on a simple soft bus for this purpose
> called "subbus". There is a RFC floating around on Mellanox internal mailing
> list, looks like it is time to send it upstream.
>
> Then each PF driver which have SFs would register subbus devices according
> to SFs/subports and they would be properly handled by bus probe, devlink
> and devlink port and netdev instances created.
>
> Ccing Parav and Jason.

Thanks Jiri for the heads up. I sent the RFC in thread [1].

[1] https://lkml.org/lkml/2019/3/1/19