[systemd-devel] persisting sriov_numvfs
Lennart Poettering
lennart at poettering.net
Tue Jan 27 08:49:01 PST 2015
On Tue, 27.01.15 08:41, Martin Polednik (mpolednik at redhat.com) wrote:
> > b) Expose this via udev .link files. This would be appropriate if
> > adding/removing VFs is a one-time thing, when a device pops
> > up. This would be networking specific, not cover anything else like
> > GPU or storage or so. Would still be quite nice. Would probably the
> > best option, after a), if VFs cannot be added/removed dynamically
> > all the time without affecting the other VFs.
> >
> > c) Expose this via udev rules files. This would be generic, would work
> > for networking as well as GPUs or storage. This would entail
> > writing our rules files when you want to configure the number of
> > VFs. Care needs to be taken to use the right way to identify
> > devices as they come and go, so that you can apply configuration to
> > them in a stable way. This is somewhat uglier, as we don't really
> > think that udev rules should be used that much for configuration,
> > especially not for configuration written out by programs, rather
> > than manually. However, logind already does this, to assign seat
> > identifiers to udev devices to enable multi-seat support.
> >
> > A combination of b) for networking and c) for the rest might be an
> > option too.
>
> I myself would vote for b) + c) since we want to cover most of the
> possible use cases for SR-IOV and MR-IOV, which hopefully shares
> the interface; adding Dan back to CC as he is the one to speak for network.
I have added b) to our TODO list for networkd/udev .link files.
c) should probably be done outside of systemd/udev. Just write a tool
(or even documenting this might suffice), that creates udev rules in
/etc/udev/rules.d, matches against ID_PATH and then sets the right
attribute.
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list