-
Notifications
You must be signed in to change notification settings - Fork 19
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 iommu groups and drivers info to resource pool #20
Conversation
Signed-off-by: Sergey Semenov <sergey.semenov@xored.com>
Signed-off-by: Sergey Semenov <sergey.semenov@xored.com>
Signed-off-by: Sergey Semenov <sergey.semenov@xored.com>
|
||
return nil | ||
} | ||
|
||
// PhysicalFunction contains information about physical function | ||
type PhysicalFunction struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like PhysicalFunction
duplicates all VirtualFunction
fields, so please consider using extension:
type PhysicalFunction struct {
TargetPCIAddress string
Capability string
VirtualFunctionsCapacity int
VirtualFunctions map[*VirtualFunction]VirtualFunctionState
VirtualFunction
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder will it be a little confusing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initialization example:
physfun := &PhysicalFunction{
VirtualFunction: VirtualFunction{
PCIAddress: pfPciAddr,
BoundDriver: KernelDriver, // Kernel driver is bound by default
KernelDriverName: pfKernelDriverName,
IommuGroup: pfIommuGroup,
NetInterfaceName: pfIfaceNames[0],
},
TargetPCIAddress: device.Target.PCIAddress,
Capability: device.Capability,
VirtualFunctionsCapacity: vfCapacity,
VirtualFunctions: map[*VirtualFunction]VirtualFunctionState{},
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about having something like that?
type NetworkFunction struct {
PCIAddress string
BoundDriver DriverType
KernelDriverName string
IommuGroup int
NetInterfaceName string
}
type VirtualFunction NetworkFunction
type PhysicalFunction struct {
NetworkFunction
other fields...
}
pkg/sriov/types.go
Outdated
) | ||
|
||
// NetResourcePool provides contains information about net devices | ||
type NetResourcePool struct { | ||
HostName string | ||
PhysicalFunctions []*PhysicalFunction | ||
IommuGroups map[int]DriverType | ||
sriovProvider utils.SriovProvider |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need utils.SriovProvider
as a part of NetResourcePool
? I believe it should be only used in InitResourcePool
and so should be passed in there as an argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you
pkg/sriov/types.go
Outdated
HostName: config.HostName, | ||
PhysicalFunctions: nil, | ||
IommuGroups: map[int]DriverType{}, | ||
sriovProvider: utils.NewSriovProvider(pciDevicesPath, pciDriversPath, iommuGroupsPath), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe such things make testing difficult. Let it be passed to the InitResourcePool
as an argument?
Signed-off-by: Sergey Semenov <sergey.semenov@xored.com>
No description provided.