Re: [dpdk-dev] kernel binding of devices + hotplug

[Matan Azrad <matan@mellanox.com>]

Hi Konstantin

From: Ananyev, Konstantin, Tuesday, April 17, 2018 12:23 PM
> To: Matan Azrad <matan@mellanox.com>; Richardson, Bruce
> <bruce.richardson@intel.com>
> Cc: Burakov, Anatoly <anatoly.burakov@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; dev@dpdk.org; pmatilai@redhat.com;
> david.marchand@6wind.com; Guo, Jia <jia.guo@intel.com>;
> stephen@networkplumber.org; fbl@redhat.com
> Subject: RE: kernel binding of devices + hotplug
> 
> 
> Hi everyone,
> Few comments from me below.
> In summary I am also in favor to keep binding decision at system level
> (outside DPDK).
> Konstantin
> 
> > -----Original Message-----
> > From: Matan Azrad [mailto:matan@mellanox.com]
> > Sent: Monday, April 16, 2018 5:11 PM
> > To: Richardson, Bruce <bruce.richardson@intel.com>
> > Cc: Burakov, Anatoly <anatoly.burakov@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>; dev@dpdk.org; pmatilai@redhat.com;
> > david.marchand@6wind.com; Guo, Jia <jia.guo@intel.com>; Ananyev,
> > Konstantin <konstantin.ananyev@intel.com>;
> stephen@networkplumber.org;
> > fbl@redhat.com
> > Subject: RE: kernel binding of devices + hotplug
> >
> > Hi Bruce
> >
> > From: Bruce Richardson, Monday, April 16, 2018 11:32 AM
> > > On Sat, Apr 14, 2018 at 08:10:28PM +0000, Matan Azrad wrote:
> > > > Hi all
> > > >
> > > > From: Burakov, Anatoly, Friday, April 13, 2018 8:41 PM
> > > > > To: Bruce Richardson <bruce.richardson@intel.com>; Thomas
> > > > > Monjalon <thomas@monjalon.net>
> > > > > Cc: dev@dpdk.org; pmatilai@redhat.com;
> david.marchand@6wind.com;
> > > > > jia.guo@intel.com; Matan Azrad <matan@mellanox.com>;
> > > > > konstantin.ananyev@intel.com; stephen@networkplumber.org;
> > > > > fbl@redhat.com
> > > > > Subject: Re: kernel binding of devices + hotplug
> > > > >
> > > > > On 13-Apr-18 5:40 PM, Bruce Richardson wrote:
> > > > > > On Fri, Apr 13, 2018 at 06:31:21PM +0200, Thomas Monjalon wrote:
> > > > > >> It's time to think (again) how we bind devices with kernel modules.
> > > > > >> We need to decide how we want to manage hotplugged devices
> > > > > >> with
> > > > > DPDK.
> > > > > >>
> > > > > >> A bit of history first.
> > > > > >> There was some code in DPDK for bind/unbind, but it has been
> > > > > >> removed in DPDK 1.7 -
> > > > > >>
> > > > >
> > >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdp
> > > > > d
> > > > > >>
> > > > >
> > >
> k.org%2Fcommit%2F5d8751b83&data=02%7C01%7Cmatan%40mellanox.com
> > > > > %7C6ea5
> > > > > >>
> > > > >
> > >
> 5ce994ff4bb0d65208d5a165b417%7Ca652971c7d2e4d9ba6a4d149256f461b%7
> > > > > C0%7
> > > > > >>
> > > > >
> > >
> C0%7C636592380565078675&sdata=uLRDAk65hYtJYxjIvY20de377yayCN5DrjCZ
> > > > > x8H
> > > > > >> p61o%3D&reserved=0 Copy of the commit message (in 2014):
> > > > > >> "
> > > > > >> 	The bind/unbind operations should not be handled by the
> eal.
> > > > > >> 	These operations should be either done outside of dpdk or
> > > > > >> 	inside the PMDs themselves as these are their problems.
> > > > > >> "
> > > > > >>
> > > > > >> The question raised at this time (4 years ago) is still under
> discussion.
> > > > > >> Should we manage binding inside or outside DPDK?
> > > > > >> Should it be controlled in the application or in the OS base?
> > > > > >>
> > > > > >> As you know, we use dpdk-devbind.py.
> > > > > >> This tool lacks two major features:
> > > > > >> 	- persistent configuration
> > > > > >> 	- hotplug
> > > > > >>
> > > > > >> If we consider that the DPDK applications should be able to
> > > > > >> apply its own policy to choose the devices to bind, then we
> > > > > >> need to implement binding in the PMD (with EAL helpers).
> > > > > >>
> > > > > >> On the other hand, if we consider that it is the system
> > > > > >> responsibility, then we could choose systemd/udev and driverctl.
> > > > > >>
> > > > > >> The debate is launched!
> > > > > >>
> > > > > >
> > > > > > Allow me to nail my colours to the mast early! :-)
> > > > > >
> > > > > > I believe it's system not application responsibility.
> > > > > > I also believe I have previously explained my reasons for that
> > > > > > choice in some of the previous email threads.
> > > > >
> > > > > For what it's worth, I tend to agree, if only because writing
> > > > > code for what is essentially a bunch of read/write/filesystem
> > > > > enumeration in C is extremely fiddly and error prone :) IMO
> > > > > things like this are better handled either by scripts, or by
> > > > > tools whose sole purpose is doing
> > > exactly that (or both).
> > > > >
> > > > > I like having scripts like devbind in DPDK because we can tailor
> > > > > them to our use cases better, and having them is amenable to
> > > > > automation, but while I wouldn't be opposed to removing them
> > > > > altogether in favor of some external tool
> > > > > (systemd/udev/driverctl/whatever), in my humble opinion moving
> > > > > them
> > > back into EAL or even PMD's would be a mistake.
> > > > >
> > > >
> > > > Since the application runs in the system by a command of the
> > > > system user I
> > > think the responsibility is for the user.
> > > > The DPDK user forwards the control of some devices to the DPDK
> > > > application using the EAL whitelist\blacklist mode to specify the
> > > > devices, Any DPDK PMD should know which binding it needs to
> > >> probe\control the device and can apply it, So, if the user asks to
> > >> control on a device by DPDK application it makes sense that the
> > >> application will do the correct binding to the device since the
> > >> user wants to use it(no need to ask more operation of pre binding from
> the user).
> > >
> > > Completely agree that it is ultimately up to the user. However, what
> > > I don't want to see is the case where the user always has to specify
> > > a big long list of device whitelist and blacklist options to each
> > > run of an application. Instead, if device management is done at the
> > > system level via udev (for example) configured via devicectl, then
> > > the application commandline can be vastly simplified.
> >
> > Actually you say that the whitelist\blacklist mechanism is not good enough
> and the binding workarounds it.
> > The user need to specify somehow the devices it want to run, I think
> > that specifying the device you want by -w option (no need to specify
> > what you don't want in -w case) is really simpler  and more descriptive than
> binding each device you want by prior process to its correct driver.
> 
> But what if user changes his mind and decides to give particular device back
> to the kernel?
> Should he restart the dpdk application? In some cases it might be not
> desirable.

And what is the behavior now in this case?
Looks like if we want to solve it we need to add mechanism to stop these particular devices DPDK management in any case.
 
> > > It also allows better usability across systems, since the same
> > > commandline can be used on multiple systems with different hardware,
> > > with the actual device management rules having been already
> > > configured at system install/setup time in udev.
> >
> > But the user still needs to configure the udev per device for each system, I
> think that command line is better.
> >
> > > > Regarding the conflict of system rules for a device, it is again
> > > > the user
> > > responsibility, whatever we will decide for the binding procedure of
> > > DPDK application the user needs to take it into account and to solve
> > > such like conflicts.
> > > > One option is to remove any binding rules of a DPDK device in the
> > > > DPDK
> > > application initialization and adjust the new rules by the PMDs,
> > > then any conflict should not disturb the user.
> > >
> > > If the device management is only managed in one place, i.e. not in
> > > DPDK, then there is no conflict to manage.
> >
> > I can't agree with this statement,
> > The essence of DPDK is to give a good alternative to managing network
> > devices, DPDK actually takes a lot of management area to manage by
> > itself to do the user life better :)
> 
> From my point - it is not about managing particular device.
> It is about making decision who (kenel/dpdk) will manage that device.

Doesn't the w\b mechanism comes to solve it?

> From usability perspective it seems to me that better to keep it in one place
> for all devices.
> So udev (or any other sysadmin tool) seems like a right choice here.

Please explain why?
And if you are talking about 1 place:
Why not to do the binding in the same place where we define which device to run?
Why not to ask from the user to specify the device and that's it?

> > Moreover,
> > Instead of bind script usage and dpdk running , just run dpdk (do all the job
> in one place).
> >
> > > > In current hot-plug case the application will need to do a lot of
> > > > work to
> > > bind\remap devices in plug-in\plug-out events while the PMD could
> > > have all the knowledge to do it.
> > >
> > > At the cost of duplicating a lot of code between PMDs.
> >
> > Why a lot of code? 1 helper in EAL to be used for each relevant PMD.
> > Each PMD just call to the EAL helper with the bind driver type.
> > Really simple and immediate.
> >
> > I think it is better than duplication of user operations.
> >

And what's about hot-plug? Who should do the bind in plug-in event?
 
> > > > One more issue with the script is that the user should do
> > > > different bind per
> > > device, in case of PMD responsibility the user can forget it:
> > > > Think about that, any time the user wants to switch\add new
> > > > supported nic
> > > it should update the script usage and to do per nic operation
> > > contrary to the DPDK principles.
> > > >
> > >
> > > The udev rules syntax should provide adequate capabilities here for
> > > us to match the correct binding behaviour. No need to have it in DPDK
> too.
> >
> > We can use it from DPDK.
> >
> > > /Bruce