[systemd-devel] persisting sriov_numvfs

[Michal Sekletar]

On Sat, Feb 14, 2015 at 12:47:54AM +0100, Tom Gundersen wrote:
> 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...

I tried this only with hardware using bnx2x driver but I don't assume that other
hardware will behave any different. Anyway, so far it *seems* like udev is not
the right place to implement this.

Michal

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