[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