> From: Jakub Kicinski <kuba@xxxxxxxxxx>
> Sent: Saturday, December 19, 2020 1:29 AM
>
> On Thu, 17 Dec 2020 05:23:10 +0000 Parav Pandit wrote:
> > > From: Jakub Kicinski <kuba@xxxxxxxxxx>
> > > Sent: Thursday, December 17, 2020 5:42 AM
> > >
> > > On Wed, 16 Dec 2020 05:19:15 +0000 Parav Pandit wrote:
> > > > > From: Jakub Kicinski <kuba@xxxxxxxxxx>
> > > > > Sent: Wednesday, December 16, 2020 6:14 AM
> > > > >
> > > > > On Tue, 15 Dec 2020 01:03:50 -0800 Saeed Mahameed wrote:
> > > > > > +static ssize_t sfnum_show(struct device *dev, struct
> > > > > > +device_attribute *attr, char *buf) {
> > > > > > + struct auxiliary_device *adev = container_of(dev, struct
> > > > > auxiliary_device, dev);
> > > > > > + struct mlx5_sf_dev *sf_dev = container_of(adev, struct
> > > > > > +mlx5_sf_dev, adev);
> > > > > > +
> > > > > > + return scnprintf(buf, PAGE_SIZE, "%u\n", sf_dev->sfnum); }
> > > > > > +static DEVICE_ATTR_RO(sfnum);
> > > > > > +
> > > > > > +static struct attribute *sf_device_attrs[] = {
> > > > > > + &dev_attr_sfnum.attr,
> > > > > > + NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const struct attribute_group sf_attr_group = {
> > > > > > + .attrs = sf_device_attrs,
> > > > > > +};
> > > > > > +
> > > > > > +static const struct attribute_group *sf_attr_groups[2] = {
> > > > > > + &sf_attr_group,
> > > > > > + NULL
> > > > > > +};
> > > > >
> > > > > Why the sysfs attribute? Devlink should be able to report device
> > > > > name so there's no need for a tie in from the other end.
> > > > There isn't a need to enforce a devlink instance creation either,
> > >
> > > You mean there isn't a need for the SF to be spawned by devlink?
> > >
> > No. sorry for the confusion.
> > Let me list down the sequence and plumbing.
> > 1. Devlink instance having eswitch spawns the SF port (port add, flavour =
> pcisf [..]).
> > 2. This SF is either for local or external controller. Just like today's VF.
> > 3. When SF port is activated (port function set state), SF auxiliary device is
> spawned on the hosting PF.
> > 4. This SF auxiliary device when attached to mlx5_core driver it registers
> devlink instance (auxiliary/mlx5_core.sf.4).
> > 5. When netdev of SF dev is created, it register devlink port of virtual
> flavour with link to its netdev.
> > /sys/class/net/<sf_netdev>/device points to the auxiliary device.
> > /sys/class/infiniband/<sf_rdma_dev>/device points to the auxiliary device.
> >
> > 6. SF auxiliary device has the sysfs file read by systemd/udev to rename
> netdev and rdma devices of SF.
>
> Why can't the SF ID match aux dev ID?
Auxiliary bus holds the SFs of multiple PFs.
SF ID can be same for SFs from multiple PFs. Encoding PCI address in SF auxiliary device name doesn't do good.
So SF ID attribute of device is more appropriate.
> You only register one aux dev per SF right?
Right.
> Or one for RDMA, one for netdev, etc?
>
These protocol/class specific auxiliary devices are on top of SF's auxiliary devices which are only for matching service purpose.
I have covered this detail with actual example in diagram in documentation in patch15 under " Subfunction auxiliary device and class device hierarchy::"
