> -----Original Message----- > From: Jiri Pirko <j...@resnulli.us> > Sent: Wednesday, February 27, 2019 6:38 AM > To: Jakub Kicinski <jakub.kicin...@netronome.com> > Cc: da...@davemloft.net; oss-driv...@netronome.com; > netdev@vger.kernel.org; Parav Pandit <pa...@mellanox.com>; Jason > Gunthorpe <j...@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.kicin...@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
