expose SRIOV information as PCI devices

[ffromani]

Expose informations about SRIOV devices. After some more design iterations (#230 (comment)), we fixed these goals:

• model SRIOV devices as special PCI devices, avoiding a new top-level package
• to shape the API, we start checking what the k8s SRIOV operator needs
• to further refine later, we will check what other projects like the k8s node feature discovery consume
• the goal is to enable such projects to switch to ghw if/when they want.

There are few more noteworthy items in this PR:

• due to lack of resources, initial support is for linux only. Nothing linux-specific should have sneaked in the API. Should the current API design make unnecessarily hard to add support on other platforms (e.g. windows) this should be treated as bug
• the code prefers Physical Functions for discovery, but we acknowledge that forcing consumers to traverse the physical functions to learn about virtual functions is awkward, so the API provides shallow references to the Virtual Functions for the sake of practicality.
• this is an alternate implementation of issue Grab information on VFs for SR-IOV PFs #92 , conflicting with expose SRIOV information #230

Fixes: #92

Signed-off-by: Francesco Romani fromani@redhat.com

[ffromani]

this PR is reviewable, but tests are still WIP. The alternate API is pretty much stable though.

[jaypipes]

@fromanirh did you want to rebase this and have it reviewed?

[ffromani]

@fromanirh did you want to rebase this and have it reviewed?

Sure, I'll rebase shortly! other than that this is not very urgent. Up to us if we like more this direction or the original one in #230

[ffromani]

note that most of the tests are missing - deferred until we settle about the direction. Should not be merged without tests, though.

[jaypipes]

@fromanirh apologies for the delayed review.

I think I would prefer to have the SRIOV-specific attributes added to the pkg/pci.Device struct itself instead of having an "extended" Function struct that derives from Device.

You could have a helper method on pkg/pci.Info called GetSRIOVDevices() that would return only the PCI devices that were SR-IOV capable. Something like this?

// GetSRIOVDevices returns only the PCI devices that are
// Single Root I/O Virtualization (SR-IOV) capable -- either
// physical of virtual functions.
func (i *Info) GetSRIOVDevices() []*Device {
    res := []*Device{}
    for _, dev := range i.Devices {
        if dev.Parent != nil || len(dev.Functions) != 0 {
            res = append(res, dev)
        }
    }
    return res
}

[ffromani]

@fromanirh apologies for the delayed review.

I think I would prefer to have the SRIOV-specific attributes added to the pkg/pci.Device struct itself instead of having an "extended" Function struct that derives from Device.

You could have a helper method on pkg/pci.Info called GetSRIOVDevices() that would return only the PCI devices that were SR-IOV capable. Something like this?

// GetSRIOVDevices returns only the PCI devices that are
// Single Root I/O Virtualization (SR-IOV) capable -- either
// physical of virtual functions.
func (i *Info) GetSRIOVDevices() []*Device {
    res := []*Device{}
    for _, dev := range i.Devices {
        if dev.Parent != nil || len(dev.Functions) != 0 {
            res = append(res, dev)
        }
    }
    return res
}

No worries @jaypipes and thank you for the review. I'm kinda reluctant to conflate even more data in the pci.Device struct (if we do than sooner or later we should also dissolve the gpu pkg into pci - which I'd like! :) ) but I don't feel so strongly to oppose this direction, so let's try and see how it looks.

[ffromani]

@jaypipes eventually I come to like this approach. We may need a couple more iteration to sort out the details of the API (naming, printing) but overall I'm happy to pursue this direction. PR is updated, rebased and ready for review

[ffromani]

depends on #351

[ffromani]

yuck, missed to update the rest of the docs :\

[ffromani]

Now that we agreed on the direction, I need to add tests. Will do ASAP.