[systemd-devel] persisting sriov_numvfs

[Tom Gundersen]

On Tue, Jan 27, 2015 at 5:49 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

I discussed this with Michal Sekletar who has been looking at this. It
appears that the sysfs attribute can only be set after the underlying
netdev is IFF_UP. Is that expected? If so, I don't think it is
appropriate for udev to deal with this. If anything it should be
networkd (who is responsible for bringing the links up), but I must
say I don't think this kernel API makes much sense, so hopefully we
can come up with something better...

> 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
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel