On 2019/11/20 上午11:38, Parav Pandit wrote:
From: Jason Wang <jasowang@xxxxxxxxxx>
Sent: Tuesday, November 19, 2019 9:15 PM
----- Original Message -----
From: Jason Wang <jasowang@xxxxxxxxxx>
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.
Just to make sure we're on the same page. Sub function is only one of
the possible cases for virtio. As I replied in another thread, we had
already had NIC that does virtio at PF or VF level. For reality, I mean
the effort spent on convincing all vendors to use devlink.
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..
To clarify, I'm not saying duplicating all stuffs through sysfs. I meant
whether we can:
1) create sub fucntion and do must to have pre configuration through
devlink
2) only after sub function is created one more available instance was
added and shown through sysfs
3) user can choose to create and use that mdev instance as it did for
other type of device like vGPU
4) devlink can still use to report other stuffs
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.
I'm not familiar with other type of devices, but they should have their
own vendor specific way to do that. That the real problems.
Thanks
