Support SRIOV PF devices

[aojea]

Bare metal platforms may require to configure the SRIO VF, I just stumbled upong this library from @adrianchiris that looks really great.

https://github.com/k8snetworkplumbingwg/sriovnet

It still requires to model the API for the consumption of the VFs from the PF, maybe with the new KEP of consumable capacity?

[alkama-hasan]

Hi @aojea i wanted to understand about this enhancement/feature
as i see currently dranet detects sriov device using
isSRIOV := sriovTotalVFs(ifName) > 0 device.Attributes[apis.AttrSRIOV] = resourceapi.DeviceAttribute{BoolValue: &isSRIOV} if isSRIOV { vfs := int64(sriovNumVFs(ifName)) device.Attributes[apis.AttrSRIOVVfs] = resourceapi.DeviceAttribute{IntValue: &vfs} }
there is two thing which i can understand here

1. There may be a better way to detect an interface as sriov capable like as you suggested using sriovnet go package
   may be replacing this code with using sriovnet package
   func sriovTotalVFs(name string) int { totalVfsPath := filepath.Join(sysnetPath, name, "/device/sriov_totalvfs") totalBytes, err := os.ReadFile(totalVfsPath) if err != nil { klog.V(7).Infof("error trying to get total VFs for device %s: %v", name, err) return 0 } total := bytes.TrimSpace(totalBytes) t, err := strconv.Atoi(string(total)) if err != nil { klog.Errorf("Error in obtaining maximum supported number of virtual functions for network interface: %s: %v", name, err) return 0 } return t }

2. currently dranet does not support capability for SRIOV VFs so we should add SRIOV VFs also as sriov capable

Is it the goal for this issue?

[aojea]

It still requires to model the API for the consumption of the VFs from the PF,

The goal of the issue is to design the feature, we need first the user stories to understand how this VFs are supposed to be consumed, who is going to create the VFs, what is the lifecycle of the VF, ...

[alkama-hasan]

we need first the user stories to understand how this VFs are supposed to be consumed

There can be multiple user stories one of them could be User Stories 2: Multi Network

who is going to create the VFs, what is the lifecycle of the VF, ...

We can assume that hardware vendor should come up with having some k8s based operator for lifecycle management of VFs or any similar things. i mean to say is we can expect the vfs are there and Dra driver's job will be to publish the resource and allocate
the similar approach is being followed by k8snetworkplumbingwg/dra-sriov-driver

[aojea]

@alkama-hasan I was the person that initiated this Kubernetes Network Driver model based on those user stories you linked, please check this paper where I summarize more in detail https://arxiv.org/html/2506.23628v1

The goal is not to create an uber driver that do a lot of things, is to have a galaxy of drivers that are composable, and I'm so happy to see the ecosystem is execution on that idea.

For DRANET specifically, we do not want to expose any internal details like this, so DRANET users should not have to understand if the interface is created with SRIOV or already exist , see more about this in #34 (comment)