[systemd-devel] persisting sriov_numvfs

[Andrei Borzenkov]

В Tue, 27 Jan 2015 03:30:22 +0100
Lennart Poettering <lennart at poettering.net> пишет:

> 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,

No, this is not limited to NICs. It is generic feature that can be in
principle used with any hardware and there are e.g. FC or FCoE HBAs
with SR-IOV support. It is true that today it is mostly comes with NICs
though.

Any general framework for setting it up should not be tied to specific
card type.
 
>                                       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
>