Re: [PATCH] Add rdma service for kernel boot support

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Thu, Jul 20, 2017 at 11:04:10AM +0200, Benjamin Drung wrote:
> Am Freitag, den 14.07.2017, 10:40 -0600 schrieb Jason Gunthorpe:
> > On Fri, Jul 14, 2017 at 06:23:13PM +0200, Benjamin Drung wrote:
> > 
> > > > My udev is not great, but something like this:
> > > > 
> > > > DRIVER=="mlx4_core", ACTION=="add", TAG+="systemd",
> > > > ENV{SYSTEMD_WANTS}="rdma-load-modules@mlx4"
> > > > 
> > > > Might work better? I think that triggers on driver bind? Could
> > > > you
> > > > try to switch your mlx and i40e drivers in that way?
> > > 
> > > I tried it. It works as expected.?rdma-load-modules@mlx4 is loaded
> > > and?
> > > rdma-load-modules-QqjR1VyAyFhTDjBF/Jpztg@public.gmane.org is not loaded. Not tested if the
> > > udev
> > > trigger will also work for used built-in modules.
> > 
> > Okay, I will change it to be like that and we can see what people
> > think.
> 
> Any updates?

I've been doing some more testing here and it does not work entirely
properly yet.

The change to 'DRIVER==' causes things to fail, the kernel only
generates uevents when kobjects are created, and binding a driver to a
PCI device does not create a kobject. This means these lines:

DRIVER=="mlx4_core", ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="rdma-load-modules@mlx4"

Do not work reliably. Depending on the module like before would still
seem to be the best option.

Also, the ordering before sysinit.target does not work reliably, udev
loads modules asynchronously and systemd does not block on udev unless
systemd-udevd-settle is depended on.

I'm not sure how Debian's legacy networking.service manages to work at
all, perhaps it is broken and it is just unlikely to be hit because of
how quickly most ethernet drivers get loaded by udev.

As far as I can tell, it needs to depend on systemd-udevd-settle to
guarentee that all the cold-plug network drivers have been loaded by
udev before starting..

.. all of these comments would seem to apply equally to the
rdma.service approach, so I think this is still an improvement.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html