-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add PoolInfo to implement discovery-time pool-specific logic #213
Conversation
/retest |
Currently PciDevice and its deviceType-specific derived versions contain two types of information - Low level device-specific information (such VF and PF names, PCI vendor, etc) used by the DeviceSelector implementations to filter devices - High level API-centric information (mounts, env, deviceSpecs) used by the ResourcePool to respond to the API calls This is fine as long as the Pool-specific information can derived solely from the PCI information. However, if a certain PCI device can be consumed in different ways (like, for instance, a device compatible with DPDK and with DPDK-vDPA) some configuration flag must be used to select which way the device should be exposed. Unfortunately, the ResourceConfig is only available when the ResorcePools are created (after the devices are). In order to make that possible, split the two types of imformation into two different interfaces (introducing PoolInfo). That way, the ResourcePool-specific data can be generated taking into consideration it's configuration. The first benefit of this cleanup is that now the Rdma deviceSpec can be appended to the rest of the device's deviceSpecs at pool-creation time and only if the pool is properly configured, thus cleaning up the resourcePool runtime code. Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
I'm waiting for some feedback regarding the high level design before starting to work on the tests. Could you ptal @ahalim-intel @zshi-redhat ? |
After adding poolInfo, we will have two places to get device related info, one is in discover phase where Do we have a clear definition in mind on when will each path be used? or shall we consider combining them to one, for example, use poolInfo for device discover? |
@zshi-redhat You're right, with this PR
In general, I think that all the properties that are not valid across all devices within a Regarding the other alternative you propose, IIUC it would entail:
I think your proposal would enable the usecase being tackled here (Same device info, different pool info). We would basically implement all the logic inside NewPciNetDevice(), that would now accept a |
makes sense to me, let's make the small change. |
This PR is intended to demonstrate #212 and propose a possible implementation (still work in progress).
Firstly, it splits the current PciNetDevice interface into two separate interfaces:
That way, InfoProviders could be selected based on ResourcePool information.
This is part of my efforts to cleanly implement vdpa support for the Device Plugin.
It can be observed how, with this preliminary rework, an experimental vdpa support can be implemented with little change in existing DP code:
https://github.com/amorenoz/sriov-network-device-plugin/tree/vdpa_pooldev