RE: [net-next v2 1/1] virtual-bus: Implementation of Virtual Bus

From: Parav Pandit <parav@mellanox.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	Dave Ertman <david.m.ertman@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"nhorman@redhat.com" <nhorman@redhat.com>,
	"sassmann@redhat.com" <sassmann@redhat.com>,
	"jgg@ziepe.ca" <jgg@ziepe.ca>,
	Kiran Patil <kiran.patil@intel.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Tiwei Bie <tiwei.bie@intel.com>
Subject: RE: [net-next v2 1/1] virtual-bus: Implementation of Virtual Bus
Date: Wed, 20 Nov 2019 03:38:18 +0000	[thread overview]
Message-ID: <AM0PR05MB48664221FB6B1C14BDF6C74AD14F0@AM0PR05MB4866.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <743601510.35622214.1574219728585.JavaMail.zimbra@redhat.com>

> From: Jason Wang <jasowang@redhat.com>
> Sent: Tuesday, November 19, 2019 9:15 PM
> 
> ----- Original Message -----
> >
> >
> > > From: Jason Wang <jasowang@redhat.com>
> > > Sent: Tuesday, November 19, 2019 1:37 AM
> > >
> >
> > Nop. Devlink is NOT net specific. It works at the bus/device level.
> > Any block/scsi/crypto can register devlink instance and implement the
> > necessary ops as long as device has bus.
> >
> 
> Well, uapi/linux/devlink.h told me:
> 
> "
>  * include/uapi/linux/devlink.h - Network physical device Netlink interface "
> 
> And the userspace tool was packaged into iproute2, the command was named
> as "TC", "PORT", "ESWITCH". All of those were strong hints that it was network
> specific. Even for networking, only few vendors choose to implement this.
> 
It is under iproute2 tool but it is not limited to networking.
Though today most users are networking drivers.

I do not know how ovs offloads are done without devlink by other vendors doing in-kernel drivers.

> So technically it could be extended but how hard it can be achieved in reality?
> 
What are the missing things?
I am extending it for subfunctions lifecycle. I see virtio as yet another flavour/type of subfunction.

> I still don't see why devlink is conflicted with GUID/sysfs, you can hook sysfs
It is not conflicting. If you look at what all devlink infrastructure provides, you will end up replicating all of it via sysfs..
It got syscaller support too, which is great for validation.
I have posted subfunction series with mdev and used devlink for all rest of the esw and mgmt. interface to utilize it.

sriov via sysfs and devlink sriov/esw handling has some severe locking issues, mainly because they are from two different interfaces.

> events to devlink or do post or pre configuration through devlink. This is much
> more easier than forcing all vendors to use devlink.
>
It is not about forcing. It is about leveraging existing kernel framework available without reinventing the wheel.
I am 100% sure, implementing health, dumps, traces, reporters, syscaller, monitors, interrupt configs, extending params via sysfs will be no-go.
sysfs is not meant for such things anymore. Any modern device management will need all of it.