[dpdk-dev] kernel binding of devices + hotplug

[Burakov, Anatoly]

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 - http://dpdk.org/commit/5d8751b83
>> 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.

-- 
Thanks,
Anatoly