> From: Leon Romanovsky <leon@xxxxxxxxxx> > Sent: Friday, October 2, 2020 5:16 PM > > On Fri, Oct 02, 2020 at 11:27:43AM +0000, Parav Pandit wrote: > > > > > > > From: Leon Romanovsky <leon@xxxxxxxxxx> > > > Sent: Friday, October 2, 2020 4:44 PM > > > > [..] > > > > > ../../../devices/pci0000:00/0000:00:0b.0/mlx5_core.eth.2 > > > > This gives you the ability to not load the netdevice and rdma > > > > device of a VF > > > and only load the vdpa device. > > > > These are real use case that users have asked for. > > > > In use case one, they are only interested in rdma device. > > > > In second use case only vdpa device. > > > > How shall one achieve that without spinning of the device for each > class? > > > > > > Why will it be different if ancillary device is small PCI core? > > > If you want RDMA, you will use specific ancillary driver that > > > connects to that small PCI logic. > > > > I didn't follow, wwhat is PCI core and PCI logic in this context? > > mlx5_core is PCI core/logic - ancillary device mlx5_ib/mlx5_en/mlx5_vdpa - > ancillary drivers > > > > > Not sure if you understood the use case. > > Let me try again. > > Let say there are 4 VFs enabled. > > User would not like to create netdev for 3 VFs (0 to 2) ; user only wants > rdma device for these VFs 0 to 2. > > User wants only vdpa device for 4th VF. > > User doesn't want to create rdma device and netdevice for the 4th VF. > > How one shall achieve this? > > It depends on how N-to-1 bus will be implemented. For example, devlink > already allows to disable RoCE on specific function, nothing prohibits to > extend it to support other classes. Sure. Please go through the our internal RFC dated 7/7/20 with subject "devlink device params to disable rdma, netdev" which exactly achieves similar. And recent 3rd internal RFC "devlink to set driver parameters" discussion with Eli, Jason, Jiri and others that describes to have one ancillary_device_per_class instead of devlink. Lets discuss it offline as we have multiple proposals floating. > > > It is easily achievable with current ancillary device instantiation per class > proposal. > > It is byproduct of 1-to-1 connection and not specific design decision. > > > > > > Being nice to the users and provide clean abstraction are important goals > too. > > Which part of this makes not_nice_to_users and what is not abstracted. > > I lost you. > > Your use case perfectly presented not_nice_to_users thing. Users are > interested to work on functions (VF/PF/SF) and configure them without > need to dig into the sysfs directories to connect ancillary classes and their > indexes to the real functions. > > Thanks
