On Mon, 16 Nov 2020 16:06:02 -0800 Saeed Mahameed wrote: > On Mon, 2020-11-16 at 14:52 -0800, Jakub Kicinski wrote: > > On Thu, 12 Nov 2020 21:24:10 +0200 Parav Pandit wrote: > > > This series introduces support for mlx5 subfunction (SF). > > > A subfunction is a portion of a PCI device that supports multiple > > > classes of devices such as netdev, RDMA and more. > > > > > > This patchset is based on Leon's series [3]. > > > It is a third user of proposed auxiliary bus [4]. > > > > > > Subfunction support is discussed in detail in RFC [1] and [2]. > > > RFC [1] and extension [2] describes requirements, design, and > > > proposed > > > plumbing using devlink, auxiliary bus and sysfs for systemd/udev > > > support. > > > > So we're going to have two ways of adding subdevs? Via devlink and > > via the new vdpa netlink thing? > > Via devlink you add the Sub-function bus device - think of it as > spawning a new VF - but has no actual characteristics > (netdev/vpda/rdma) "yet" until user admin decides to load an interface > on it via aux sysfs. By which you mean it doesn't get probed or the device type is not set (IOW it can still become a block device or netdev depending on the vdpa request)? > Basically devlink adds a new eswitch port (the SF port) and loading the > drivers and the interfaces is done via the auxbus subsystem only after > the SF is spawned by FW. But why? Is this for the SmartNIC / bare metal case? The flow for spawning on the local host gets highly convoluted. > > Also could you please wrap your code at 80 chars? > > I prefer no to do this in mlx5, in mlx5 we follow a 95 chars rule. > But if you insist :) .. Oh yeah, I meant the devlink patches!
