netdev - Re: [net-next v5 07/15] net/mlx5: SF, Add auxiliary device support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201218115834.0f710e0c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Fri, 18 Dec 2020 11:58:34 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Parav Pandit <parav@...dia.com>
Cc:     Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jason Gunthorpe <jgg@...dia.com>,
        Leon Romanovsky <leonro@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        David Ahern <dsahern@...nel.org>,
        Jacob Keller <jacob.e.keller@...el.com>,
        "Sridhar Samudrala" <sridhar.samudrala@...el.com>,
        "david.m.ertman@...el.com" <david.m.ertman@...el.com>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "kiran.patil@...el.com" <kiran.patil@...el.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Vu Pham <vuhuong@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [net-next v5 07/15] net/mlx5: SF, Add auxiliary device support

On Thu, 17 Dec 2020 05:23:10 +0000 Parav Pandit wrote:
> > From: Jakub Kicinski <kuba@...nel.org>
> > Sent: Thursday, December 17, 2020 5:42 AM
> > 
> > On Wed, 16 Dec 2020 05:19:15 +0000 Parav Pandit wrote:  
> > > > From: Jakub Kicinski <kuba@...nel.org>
> > > > 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? You only register one aux dev per
SF, right? Or one for RDMA, one for netdev, etc?

> Steps 4,5,6 are equivalent to an existing VF.