[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Nov 2019 05:18:57 +0000
From: Parav Pandit <parav@...lanox.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC: Jason Gunthorpe <jgg@...pe.ca>, Jiri Pirko <jiri@...nulli.us>,
David M <david.m.ertman@...el.com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Saeed Mahameed <saeedm@...lanox.com>,
"kwankhede@...dia.com" <kwankhede@...dia.com>,
"leon@...nel.org" <leon@...nel.org>,
"cohuck@...hat.com" <cohuck@...hat.com>,
Jiri Pirko <jiri@...lanox.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
Or Gerlitz <gerlitz.or@...il.com>
Subject: RE: [PATCH net-next 00/19] Mellanox, mlx5 sub function support
> -----Original Message-----
> From: kvm-owner@...r.kernel.org <kvm-owner@...r.kernel.org> On Behalf
> Of Jakub Kicinski
> Sent: Sunday, November 10, 2019 9:46 PM
> On Sun, 10 Nov 2019 10:18:55 +0100, gregkh@...uxfoundation.org wrote:
[..]
> The nice thing about having a fake bus is you can load out-of-tree drivers to
> operate extra protocols quite cleanly.
>
This series does NOT intent to do any out of tree driver.
Please do not think in that direction for this series.
> I'm not saying that's what the code in question is doing, I'm saying I'd
> personally like to understand the motivation more clearly before every
> networking driver out there starts spawning buses. The only argument I've
> heard so far for the separate devices is reloading subset of the drivers, which
> I'd rate as moderately convincing.
Primary objectives behind using a bus in this series is:
1. get same level of device view as PF/VF/SF by devlink instance
2. to not re-invent already matured pm (suspend/resume) in devlink and/or vendor driver
3. ability to bind a sub-function to different drivers depending on use case based on 'in-kernel' defined class-id
(mdev/virtio/kernel) - just like vfio-pci and regular PF driver, by following standard driver model
(Ofcourse, It can be done using 3 or more buses as one virtual mdev bus appears an abuse)
4. create->configure->bind process of an sub function (just like a VF)
5. persistent naming of sf's netdev and rdmadev (again like PF and VF)
I will wait for Jason's and Jiri's view on the alternative proposal I sent few hours back to omit bus for in-kernel use of sf; and see how far can we run without a bus :-)
Powered by blists - more mailing lists