[systemd-devel] persisting sriov_numvfs

[Lennart Poettering]

On Fri, 23.01.15 08:51, Martin Polednik (mpolednik at redhat.com) wrote:

> > Quite frankly, I cannot make sense of these sentences. I have no clue
> > what a "SR-IOV", "virtual function", "physical function" is supposed
> > to be.
> > 
> > Please explain what this all is, before we can think of adding any
> > friendlier config option to udev/networkd/systemd for this.
> 
> Hello,
> 
> I'm oVirt developer responsible for VFIO/SR-IOV passthrough on the host
> side.
> 
> SR-IOV is a specification from PCI SIG, where single hardware device
> (we're using NICs for example) can actually act as a multiple devices.
> This device is then considered PF (physical function) and spawned devices
> are so called VFs (virtual functions). This functionality allows system
> administrators to assign these devices to virtual machines to get near
> bare metal performance of the device and possibly share it amongst multiple
> VMs.
> 
> Spawning of the VFs was previously done via device driver, using max_vfs
> attribute. This means that if you wanted to persist these VFs, you had to
> add this to modules-load.d. Since some of the device driver creators used
> different names, spawning of VFs was moved to sysfs and can be operated via
> echo ${number} > /sys/bus/pci/devices/${device_name}/sriov_numvfs where
> ${number} <= /sys/bus/pci/devices/${device_name}/sriov_totalvfs and if 
> changing the number of VFs from nonzero value, it first needs to be set to 0.
> 
> We've encountered the need to persist this configuration and load it before
> network scripts (and possibly in future other scripts) so that the hardware
> can be referenced in those scripts. There is currently no such option. We
> are seeking help in creating a standardized way of handling this persistence.

Hmm, I see. In many ways this feels like VLAN setup from a
configuration PoV, right? i.e. you have one hw device the driver
creates, and then you configure a couple of additional interfaces on
top of it.

This of course then raises the question: shouldn't this functionality
be exposed by the kernel the same way as VLANs? i.e. with a
rtnetlink-based API to create additional interfaces, instead of /sys?

In systemd I figure the right way to expose this to the user would be via
.netdev files, the same way as we expose VLAN devices. Not however
that that would be networkd territory, and RHEL does not use
that. This means you'd have to talk to the NetworkManager folks about
this...

Anyway, Tom, I think you should say something about this!

Lennart

-- 
Lennart Poettering, Red Hat