sriov-network-device-plugin
sriov-network-device-plugin copied to clipboard
k8snetworkplumbingwg
Extend mediate device (mdev) support for device plugin.
Sriovdp can work as a generic device plugin for all vfio devices. mediated device (mdev) is a recent addition to linux vfio framework that is currently used by, e.g. Intel Graphics Virtualization (GVT-g).
This patch adds capability for system administrators to enable mdev devices for containers.
Signed-off-by: Terrence Xu [email protected]
@TerrenceXu very interesting work. I am aware that sriov network device plugin could have been utilized for non-networking PCI devices even though that was not the primary intent of this plugin. I don't think we have any networking use-cases with this changes. Besides, in our roadmap we are moving away from PCI address based resource pool and moving towards a "selectors" based resource pool. Please see the branch feature/device_selectors for all related changes. We are planning to merge this branch into master branch pretty soon. Please note, the device selector branch limit itself discovering network devices only.
I would suggest to add this feature for the GPU plugin(if that is the primary usecase of mdev) itself by re-using(vendoring) codes as needed.
This PR was created to avoid the need for a dedicated (v)GPU plugin because a generic PCI plugin is already available (this plugin). With device selectors, how do you plan to support the community that depends on what is supported today?
This is a question of granularity vs usability. PCI address based resource configuration allows creating resource pool purely based on the PF's physical address, but in reality its harder to deploy(having to figure out all PCI addresses in the cluster). The selector based approach can cover pretty much all use-cases we needed for discovering and allocating sriov network devices. As you can see there are number of PRs already there to extend it's functionality(resource pool from specific PF names as oppose to it PCI address - which is more flexible in our opinion). Users wish to continue use PCI address based resource configuration can do so using older release(before the device selector feature merge). We will fix any known bugs. But no addition feature will be added to them.
@ahalim-intel
The selector based approach can cover pretty much all use-cases we needed for discovering and allocating sriov network devices
I briefly checked the branch you have WIP. Are you intentionally filtering out all but netClass devices? I'm thinking would the class be a selector too?
The mdev use case does not depend on the previous implementation as such (PCI address). Are you against making it possible to have mdev devices usable in our new approach?
@mythi
Are you intentionally filtering out all but netClass devices?
Yes that is correct. We wanted to keep our scope limited to SR-IOV network devices only. This is because we needed to validate and process available network devices further. It is done to decide if a device is SRIOV PF or VF, whether the SRIOV configured, checking network link status and most importantly to exclude out network devices that are in-use by the host already. I'm sure these are not applicable to non-networking devices.
Are you against making it possible to have mdev devices usable in our new approach?
We are absolutely not. In fact, the selectors were introduce quite long back before this mdev PR. We'd be more than happy to re-purpose this device plugin for other use cases. But without compromising/complicating the networking use cases.
By the way, originally we developed this plugin for SR-IOV NICs only in mind and this is what the name reflects too. But if we want to use this plugin as a framework for other kinds of devices OR even for SRIOV NICs themselves then we should have a separate discussion on that. Having feature included under the "sriov-network-device-plugin" for non-network use-cases do not communicate well for this plugin nor for that feature itself.
stale PR, closing part of housekeeping. re-open / rebase / rework if its still relevant
